At work we’ve been having an ongoing discussion about how to manage identity for our internal applications. We have a number of functions we need to implement, all of which will need to be tied to a user’s identity. We’d like to use a mix of applications we write ourselves and off the shelf applications, and the big question we’re facing is how to manage identity across all of these applications. This sort of goes back to a post I made awhile back noting that increasingly people are just tying into the user registration system for packages like PHPbb as a quick and dirty solution to this problem.
We’ve sort of come to a decision that the best approach is to have two systems, our identity management system, which other applications can integrate with at the Web service level or database level, and an LDAP service. That’s all well and good, but there are still a couple of questions that we’re wrestling with — how to get users who register on the Web site into LDAP and where to put the user registration code. Right now, we’re planning on writing a standalone user registration/management application, but then each application that uses it will have its own roles and privileges. Should they share one table for roles and privileges or should each application maintain its own?
I think the problem’s we’re seeing explain why the big cross-company identity systems have never taken off to a great extent. It’s hard enough when you control all of the applications and the database, the complications only grow when you’re talking about integrating with someone else’s identity application. Sometimes I think that maybe just having a bunch of different user names and passwords is easier.
January 12, 2006 at 6:42 pm
Next system I write will allow users to have a YADIS defined LID identity locally, or use YADIS if they want to use a LID or OpenID identity from elsewhere.
Subsystems will be able to use the resulting URL as the primary key on their privileges table, and there may be integration on how those privileges get maintained (ie: They may be views on a master table that there’s a tool to manipulate), but as much as possible I’ll want to be able to deploy a subsystem independently.
January 12, 2006 at 10:11 pm
Oddly, I was just talking about single sign-on over lunch. Sure is tricky! In our application I approach it by storing our own password, but leaving the opportunity to put the authentication hooks into another system. Nobody yet is doing that though.
January 13, 2006 at 3:26 pm
I don’t know about “Nobody yet is doing that”. There are patches to use LID and OpenID with MediaWiki, I’d guess that there’s an LiveJournal is providing OpenID sign-ons (and will soon provide YADIS discovery, presumably allowing LiveJournal users to publish LID URLs along with OpenID ones).
(And my weblogging software is a LID consumer, but that isn’t exactly mainstream…)
So, yeah, Single sign-on is real. The folks behind the two leading systems right now are cooperating. There’s lots of example software for implementing either or both of the systems.
And the next web app I architect (which probably won’t be soon, ’cause I’m a 3d programmer, not a web person) will definitely use one of those specs, probably LID, to communicate identity between modules.
January 15, 2006 at 1:54 am
The way I like to see the whole Identity and access management is to break the piece into two parts. The first part being the authentication and role assignment. This in the system that you are proposing would be done by the user registeration and authentication system.
The other part of the privilege based on Role (RBAC) will be built into the application and application would evaluate whether to give access to user based on the role that the user belongs to. Now the transfer of role information from authentication can be done by either token (like SAML) or by runtime query (like User-Identity system based on YADIS)
March 27, 2006 at 1:02 am
Nice blog you Gotcha here
March 28, 2006 at 3:27 pm
No Fax Payday Loans http://www.idealpaydayloans.com/payday-loans-no-fax.htm