Tuesday Jun 26, 2007

Filling the Atompub AAA void with an OpenDS backed Atom server

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 and audit 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.

Wednesday Jun 13, 2007

OpenDS and Atom - enabling Web 2.0 behind the firewall

The latest Identity Management Buzz podcast features Brandon Whichard, Don Bowen, and myself discussing Atom, the Atom Publishing Protocol, OpenDS, and how these technologies intersect. Give it a listen. IMO, we cover the highlights without stretching your noodle.

Monday Jun 04, 2007

OpenDS Atom server up to snuff

The OpenDS Atom server is now compliant with the latest Atompub (draft 15) specification and passes all APE tests to include: adding, updating, deleting atom entries and associated media resources. Next up, a bit more hardening and user documentation.

Friday May 25, 2007

Atom and LDAP sitting in a tree...

"Tree", as in a directory information tree. Its been slightly over a year since Don and I had a gee whiz moment to front end the directory server with Atom and the Atom Publishing Protocol (APP). A year ago might have been a bit too early for a directory based APP server, though its clearly the right time now. Why?
  • Finally, there's a directory server that is lightweight, very fast (read AND write), and developer friendly - OpenDS
  • The APP spec appears to be close to completion
  • Facilities for search and user authorization are noticeably absent from the APP spec (that's a good thing)
  • DSML (LDAP over XML) is deader than a doornail
  • Think "syndicated databases"; i.e., databases queried, edited and generally mangled via feeds. I know I'm not the only one thinking about it (checkout Google GBase and Yahoo Pipes).

Atom, APP, and OpenDS
  • Atom is a simple, extensible specification that describes lists of related information. In its simplest form it is no more than a blog feed.
  • APP is a web-based protocol for publishing, editing and retrieving web resources; e.g., Atom documents, xhtml, images, podcast episodes, et al. APP relies on tried and true HTTP and ReST interfaces gaining it a distinct advantage over previous attempts. That is, a widely deployed infrastructure, simple to grok, and relatively simple server and client side implementations.
  • OpenDS is an open source, 100% Java directory service

Why is an OpenDS based Atom server interesting?
  • I have yet to see an Atom/APP implementation application that is identity aware. That is, a server that has intrinsic user knowledge with regards to roles, authorization, authentication mechanisms and user relationships
  • Most certainly not file based. Resources posted and fetched are stored in the directory thus enabling synchronization, access control, search, etc.
  • Powerful, ReST search based on LDAP Urls
  • Built on a scalable architecture. Back-ended by OpenDS, front-ended by Glassfish application server, and written atop Java

What can you do with it?
  • "Web 2.0" enable your directory. Atom is easily parsed within a web browser and for that matter any other HTTP agent. Therefore, access to the info rich directory is more accessible to external applications and more easily programmed by the neophyte LDAP developer.
  • Centrally secure, replicate, and backup Atom documents;e.g., blogs in the directory
  • Re-use existing infrastructure and expertise (directory server) to store next gen web content, again, in a secure, scalable fashion
  • Monitor the directory through feeds. A simple search on the OpenDS monitor (/atom/search?q=cn=monitor??sub?) dumps a feed of all significant directory statistics
  • ...

Where can you get it (and contribute to it!)?

Right here, in the first OpenDS sub-project @ http://atom.dev.java.net




« August 2016