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.