Managing large user databases for single-signon.

How would you implement a system with the following objectives:

• Manage authentication, authorization for hundreds of thousands of existing users currently tightly integrated with a 3rd party vendor's application (We want to bust these users out into something we manage and make our apps work against it, plus our 3rd party vendors work against it).
• Manage profile information linked to those users
• Must be able to be accessed from any number of web applications on just about any platform (Windows, *nix, PHP, ASP/C#, Python/Django, et cetera).

Here some sample implementations:

• LDAP/AD Server to manage everything. Use custom schema for all profile data. Everything can authenticate against LDAP/AD and we can store all sorts of ACLs and profile data in a custom schema.
• Use LDAP/AD for authentication only, tie LDAP users to a most robust profile/authorization server using some sort of traditional database (MSSQL/PostgreSQL/MySQL) or document based DB (CouchDB, SimpleDB, et cetera). Use LDAP for authorization, then hit the DB for more advanced stuff.
• Use a traditional database (Relational or Document) for everything.

Are any of these three the best? Are there other solutions which fit the objectives above and are easier to implement?

** I should add that almost all applications that will be authenticating against the user database will be under our control. The lone few outsiders will be the applications we're removing the current user database from and perhaps 1 or 2 others. Nothing so broad as to need an openID server.

Its also important to know that a lot of these users have had these accounts for 5-8 years and know their logins and passwords, et cetera.

From stackoverflow $pageUsers[$entry.posts[0].author].name

• You can always implement your own OpenID server. There is already a Python library for OpenID so it should be fairly easy.

  Of course you don't need to accept logins authorized by other servers in your applications. Accept credentials authorized only by your own server.

  Edit: I have found an implementation of OpenID server protocol in Django.

  Edit2: There is an obvious advantage in implementing OpenID for your users. They will be able to login to StackOverflow with their logins :-)

  From zuber

• If you have an existing ActiveDirectory infrastructure, that will be the way to go. This will be particularly advantageous to companies that have already had Windows servers set up for authentication. If this is the case, I'm leaning towards your first bullet point in "sample implementations".

  Otherwise it will be a toss-up between AD and opensource LDAP options.

  It might be not viable to roll your own authentication schema for single-sign-on (especially considering the high amount of documentation and integration work you might have to do), and obviously do not bundle your authentication server with any of the applications running on your system (since you want it to be able to be independent of the load of such applications).

  Goodluck!

  jms : What's nice about LDAP is other third party products for the enterprise should be able to connect to it for user management.

  Jon Limjap : Depends on the profile information. If the Profile information is application-specific, I think you should store it with your application. If it's stuff that's going to be used across applications, LDAP should accommodate that information, IMHO.
  From Jon Limjap

• There is a difference between authentication and authorization/profiling so don't force both necessarily into a single tool. Your second solution of using LDAP for authentication and a DB for authorization seems more robust as the LDAP data is controlled by the user and the DB would be controlled by an admin. The latter would likely morph in structure and complexity over time, but authentication is just that authentication. Separation of these functions will prove more manageable.

  From dacracot

• Use LDAP/AD for authentication only, tie LDAP users to a most robust profile/authorization server using some sort of traditional database (MSSQL/PostgreSQL/MySQL) or document based DB (CouchDB, SimpleDB, et cetera). Use LDAP for authorization, then hit the DB for more advanced stuff.

  jms : I choose this as a "safe" answer as I'm not sure how flexible LDAP schema changes are once in production. However I feel very comfortable using it for a user store while modifying a database as features are added.
  From jms

• We have different sites with around 100k users and they all work with normal databases. If most applications can access the db you can use this solution.

  From Sklivvz