Some Notes on Identity Management in OpenQabal
Some quick notes on what's going on with the Identity related stuff in OQ. Not necessarily in order: 1. One of the key concepts in OQ is the notion of federated identity... that is, an identity associated with one install of OQ should be "usable" from another install, where "usable" might mean "user at Site A can list user at Site B as a friend" or it might mean "user from Site B can login at Site A" or it might mean both, or it might mean neither. 2. That said, part of the idea of OQ, at any given install, is to be a sort of "social operating system" that enables application integration based on "social" technologies (the social graph, social ranking/voting, etc). 3. The use cases around (2) above are where some actual work has been done, and stuff works. We currently integrate apps running in the same domain by using JA-SIG CAS, with the authentication backend being our own simplistic IdM system (refered to as the IdentityEngine). 4. At one time it seemed to make sense to have the IdentityEngine project there to act as a mediator / bridge to possible other existing enterprise IdM systems. In retrospect, I'm no longer sure that adds much value. 5. It's entirely possible that a better approach would be to rip out the existing OQ IdM 'stuff' and just plop in Sun's OpenSSO / OpenFederation / OpenDS / OpenPTK stack. I'm doing some research on that point at this very moment, while also continuing to work on the existing OQ stuff based on CAS and the IdentityEngine. 6. Part of the point in rolling out this initial, somewhat naive, built-in IdM was to give us a test platform to experiment with issues around (1) above. To that point, I've been working on the possibility of making CAS an OpenID Relying Party, so that a user can login to OQ through OpenID and get the full CAS SSO experience. 7. Much research still needs to be done to sort out the best approach(es) to handling (1) above. OpenID may well be part of that solution, along with OAuth, but don't hold me to that. SAML, WS-Federation and some of the Liberty Alliance stuff may also be useful. Still need to do more research there. 8. What works now is this: SSO using CAS, successfully integrates Roller, JavaBB and our "User Console" app. Roller has a mechanism for fully externalizing user management, so it's not technically required to provision a new user into the Roller user table, although that code is still in place at the moment. JavaBB, on the other hand, does not (yet) have that ability, so when we create a new user, we have to populate the JavaBB user table. 9. One of the big things I want to determine is "what are the implicatiosn for user provisioning, when using an external authentication source like OpenID?" See comment (6) above. Getting that done will enable some experimenting around how this will work in principle. 10. User provisioning with SPML is also of interest. 11. The IdentityEngine exposes remote interfaces using EJB3 SLSBs, this is used by our implementation of the pluggable UserManager in Roller (there are use cases which require exposing APIs like "get list of users" and "get user by name" etc. In addition, we have to be able to authenticate "out of band" to enable authentication for the MetaweblogAPI interface (and presumably APP as well). 12. Another point that has not been addressed at all is two-factor (or multi-factor in general) authentication. If anything else comes to mind, I'll make a follow up post. Please send other questions to the dev@ mailing-list...Syndicated 2008-11-18 04:37:53 (Updated 2008-11-18 04:46:42) from openqabal