May 6^th 2003

AuthZCenter Project

Parviz Dousti

What is it?

AuthZCenter is basically a part of LDAP tree which is setup and allocated for storing and retrieving ACLs.  Applications would consult it to determine permission of a Person or an Account for accessing a resource. 

How is it done?

             Two new trees would be set up in LDAP under a new ou (e.g. ou=authz,dc=cmu,dc=edu). There would be one tree for persons and one for accounts (similar to what we already have). Every person or account at CMU has an entry which is the collection of their “rights” to some resources.  Every resource is represented by an attribute.  Attributes can be single or multi-valued and of different types. Value(s) of the attribute determines the right of the person or account to that resource.

Pros:

             - Centrally administrated.

             - Provides the indirection required to deal with exceptional cases to administratively allow or deny.

             - More likely to integrate with of-the-shelf software packages.

             - Not cluttering the Person and Account records with extra attributes.

             - Minimum work for most existing applications.

             - Uses LDAP protocol which is standard and easy to implement for applications.

             - A relatively long term solution which fits nicely with our long term plans.

             - Policy engine is extracted nicely so can be improved overtime without disrupting applications.

Cons:

- It is a network based authorization.  If network or LDAP server is down then cannot check authorization.  (One solution for some network critical apps is to harvest LDAP overnight and build their own local data).

- Extra work is needed to keep the AuthZCenter up-to-date and in sync with Person and Account trees.

- New application would require new attributes which is not easy to add to LDAP.

What is required?

             - From application point of view:

- Applications don’t need to do much. To find out if a user has access to a resource or determine their entitlements, they simply look up that user (person or account) in a special part of LDAP and get the attribute associated with that resource. 

- Need to speak LDAP protocol. 

- Might need to use SASL.

- They can optionally harvest the tree periodically.

- From administrator’s point of view:

- An application is needed to allow administrators to create and maintain resources (i.e. new attributes).

- A mechanism needed for setting attribute values based on a certain policy and inputs (e.g. a policy engine or a trigger mechanism).

- A user interface to allow setting of attributes administratively (single or multiple entries).

- A history for auditing the changes.

How does it fit with our long term plans?

             This should be a nice stepping stone toward a more complex policy engine.  We might even imagine using Ponder to set these attributes based on a set of rules.

What to do next?

             - Contact application maintainers and explain the new authorization policy.

             - Collect the attributes they need for each existing application.

             - Collect attributes for projects under development.

             -  Set up LDAP trees.

             -  Populate the trees from existing Person and Accounts tree with default values.

             -  Develop triggers to keep these trees in sync with Person and Account.

             - (At this point applications can begin to use the new system)

             -  Hand craft triggers to change attributes based on graduation/alumni policy.

             -  Develop a “history” trigger.

             -  Develop an admin UI

A stab at AuthZCenter project requirements:

Here are the requirements for AuthZCenter:

1- Authorization can be done based on the account used for authentication OR the Person using the application but each application (or at least resource) would be either on account OR person and not both.

2- From the application point of view this has to be simply getting value of an attribute from LDAP.

3- AuthZCenter has to be separate from Account or Person information section of LDAP tree.

4- It should be easy to add new attributes (resources) for a given application or new applications.

5- Account and Person entries in AuthZCenter must be kept in sync with the main tree.  Of course no need to sync attributes.

6- Attribute values are set based on certain logic and maybe other attributes of a person or account.  This is only for initial setting and the values can be administratively changed.  It should also be possible to trigger off of an attribute in this part of the tree (ACL based on another ACL).

7- System should allow for adding new policies that determine the value of an attribute.

8- It should be easy to back fill existing entries with a new attribute (and appropriate values).

9- There must eventually be a user interface for administration of AuthZCenter that supports single and multi-record manipulations.

10- History of all changes must be kept for auditing.

11- ACL look ups should be fast and almost always possible (availability).