I'm not sure how much hassle it would be to allow OpenACS to answer to ldap, kerberos, x.509, radius, you name it, authorization requests.
A glib answer is: parametrize
ad_check_password to use one of any number of available password checkers. I think an abstraction along these lines is certainly a good start no matter what mechanism---web services or whatever---the password checkers use to connect to external authentication servers. This is, of course, just the tip of the iceberg...
Furthermore, will we need to store the user data in all the one place or keep it in multiple places. Should a user be able to update his adress in one place, but use it in all applications? How can this be handled
Great question. Have you ever noticed how on every project, the client wants to store a slightly different set of per-user fields? It seems to me that there should be some abstraction around the set of fields we store for a user. That abstraction could further define the conditions under which local data about the user, for example their first and last names, should be treated as canonical or not and whatever consequences that entails. There are a couple of sections in OACS and dotLRN that from their names sound like what we want ("user-extensions-procs" and "profile-provider") but if I'm reading the code correctly, these serve other purposes.
