Authentication, Authorization and Accounting, or "triple A", are key requirements for enterprise applications and if Web 2.0 apps are to succeed behind the firewall they too must integrate within the hairball that is the enterprise. The Atom syndication server
backed by the OpenDS
LDAP server cleanly address the issues and here's how:
Authentication: Assertion that the user is who they claim they are; e.g., via username/password
The Atom publishing protocol specification
recommends that servers implement a mechanism to ensure agents performing write operations are authenticated. Authentication is handled as follows:
- The user agent is prompted for credentials when an agent performs a POST, PUT, DELETE, and in some cases, a GET request
- In the typical case, a username and password or posted using HTTP BASIC
- The username and password are used to perform an LDAP bind that asserts that the user is present in the directory server and the provided password matches
- On success the principal is stored in the Atom server and a client token is sent in response for future client interactions with the server. Nothing new here.
Authorization: What resources can the authenticated user access and what can they do with them.
The server leverages the underlying servlet container for coarse grained access control and the directory for fine grained control. All atompub operations are protected using container access control that, in the end, simply requires that the user belong to an administratively defined LDAP group; e.g., "atompubwriters". That is, the container simply checks that the context's principal is a member of the appropriate LDAP group.
Fine grain access control is a bit more interesting. In most enterprise applications access controls must be implemented at least twice; 1) the user interface (API or GUI); e.g., locking down fields, screens, modules, etc. and 2) in the database (field, table, etc). Obviously, this is difficult to maintain and when database connection pooling is thrown in the mix correlating the "real" user and the database connection is no longer feasible since the "real" user is lost.
OpenDS solves the connection pooling identity problem with the "proxy authorization control"
and fine grain access control with access control instructions (ACIs)
. The proxy auth control enables the developer to create a connection pool with a common user, say "atomproxy", with just enough privileges to connect to the directory. When a connection is taken from the pool the proxy auth control containing the principal name is attached to the connection thus propagating the real user to the directory. The directory server, recognizing that the proxy auth control is present, uses the proxy principal versus the connection principal to determine access rights. Hence, you get the best of both worlds - connection pooling performance and preservation of end user identity.
For the most part, ACI's are used to narrow or widen user access to some part of the directory information tree. In the case of the Atom syndication server ACI's are added allowing end users write access beneath their LDAP entry enabling them to add blog entries, media resources (podcasts, pictures), etc. Other ACIs are used to filter content available to anonymous users (unauthenticated searching of the Atom server). By using ACI's versus application specific access control a system adminstrator can reliably set user access permissions in a single place throughout the enterprise - the directory.
Accounting/Auditing: Record of user/resource activity; e.g., who changed what when
Accounting comes free! Out-of-the-box OpenDS provides both access
logging. The former captures who and what was modified and the latter the contents of the modification (the specific data changes). Further, OpenDS logging/auditing is extensible, hence custom auditing loggers can be written for domain/application specific purposes.