Forum .LRN Q&A: External Authentication

Posted by Alfred Essa on 08/30/02 08:39 PM

I wanted to post some questions about achieving external authentication, which everyone would agree should be available in dotLRN. I am not a developer so pardon me if I am not understanding the technical issues properly. There seem to several approaches and I would look to receive some comments:

Write a separate interface for each external authentication service as need (ldap, kerberos, x.509, radius, etc); this is the one-off approach;
Write something general? within OpenACS/dotLRN and implement different instances;
Expose authentication as a web service. I am not sure what this means exactly, but is it feasible to expose LDAP authentication service, for example, as a web service and then have .LRN utilize it?
Implement Open Knowledge Initiative (OKI) APIs, which are currently expressed in Java;

I am particularly interested in the the web service approach. Is this worth investigating?

What do people recommend for us getting off the ground with achieving external authentication. How should we be attacking this? Is this a difficult problem? What kind of resources/funding will be required?

2: Response to External Authentication (response to 1)

Posted by Carl Robert Blesius on 08/31/02 12:04 AM

I would like to see a generalized solution in OpenACS (something that would allow anyone to add new authentication sources as needed without intimate knowledge of OpenACS). What would be the best way to do this? Is there a way to do it that would allow us to tap into existing code (e.g. pam modules[1])? What about...

External authentication without loosing the "I forgot my password... please send me a new one" function
Fallback mechanisms: e.g. check LDAP... if not in LDAP check Active Directory... if not in AD check the OpenACS DB
Single signon: e.g. logon to the campus (or company) IMP WebMail[2] server and seemlessly surf over to the dotLRN/OpenACS server without having to reauthenticate (something that allows policies that define which systems should have shared authentication)
Automatic signon: as in one system on the other side of the world accepting the authentication of another (cross-institutional authentication and authorization services... see Sibboleth[3]... .NET Passport[4])

Is OKI AuthN API the answer[5]? Is this a good time to think about a IMS[6] ID for users as well?

[1] http://www.kernel.org/pub/linux/libs/pam/modules.html [2] http://www.horde.org/imp/
[3] http://middleware.internet2.edu/shibboleth/shibboleth-project.html
[4] http://www.microsoft.com/netservices/passport/
[5] http://web.mit.edu/oki/specs/specs-authn.html
[6] http://www.imsglobal.org/specifications.cfm

3: Response to External Authentication (response to 1)

Posted by Carl Robert Blesius on 08/31/02 12:16 AM

please replace "loosing" with "losing" :)

4: Response to External Authentication (response to 1)

Posted by Malte Sussdorff on 08/31/02 02:18 PM

Hi Carl, Al,

for AIESEC we needed to implement a single signon and authentification for IMP Mail and another system, not using LDAP.

What we ended up doing was storing the password of the other application in our database and send these information through a redirect / registration page.

As for LDAP, it was easy to get ACS to use LDAP, which IMP was using as well. We have portlets showing you the latest email in your mailbox.

But this was always a fix for a certain situation. Maybe we can explore in using something like Passport or anything else that allows us a single signon process for multiple applications. But always be aware, that ACS will only be one application among many, so we might be stuck with other applications who do not like single authorization/signon.

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 (we use direct database communication, which is not really the way to go, but it was fast and convenient).

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. But if it is fairly easy, this might be the preferrable way, with exporting the user data add/edit function as a webservice as well, so we could plug this in the webmail functionality. But here again, webservices still seems to me like a lot of vapour ware.

Concerning the OKI API, would it be possible to just load them into ns_java and access them from there ?

5: Response to External Authentication (response to 1)

Posted by Andrew Grumet on 08/31/02 05:08 PM

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.

6: Response to External Authentication (response to 1)

Posted by defunct defunct on 09/02/02 10:43 AM

Andrew,

Surely that's already catered for by virtue of the extensible data model?

i.e. just extende the existing 'users' table to create you new 'detailed-users' table and you're away!

7: Response to External Authentication (response to 1)

Posted by Andrew Grumet on 09/02/02 06:08 PM

i.e. just extende the existing 'users' table to create you new 'detailed-users' table and you're away!

Right. What I'm thinking of goes a few steps beyond that. Note that when you add detailed-users, you also have to modify the "update my information" and "public information about this user" pages. Is it better to do this as a one-off for each project, or would we gain something by making it easier for programmers to get the UI they want without having to modify core files? There are probably several ways we could accomplish this (use of service contracts or parameters or metadata-driven UI) but I haven't thought deeply about it.

8: Response to External Authentication (response to 1)

Posted by Carl Robert Blesius on 09/03/02 12:08 AM

Not having to modify core files would be important, in fact it would be nice to be able to add custom user fields as needed using the site admin-UI. Something along the lines of the custom fields for photos at photo.net (if I remember correctly).

9: Response to External Authentication (response to 1)

Posted by defunct defunct on 09/03/02 10:25 AM

Yes, I see what you're getting at. And I suppose I agree in principle.

This issue however applies system wide. Every package we've ever used has needed work on its 'core' files to suit our purposes. I suspect thats pretty true of most people (?).

Therefore what you suggest is actually applicable all over the place.

The problem I can see is one of compromise. To instigate this level of 'customisation' in each package would surely represent a compromise in terms of performance/maintenance/development. Also, given that in any site, the 'users' are likely to be one of the most commonly referenced elements, that compounds the difficulty in this case. (unless someone has a whiz bang clever way to do it).

Perhaps an alternative (and I'm by know means backing it) would be to consider what 'core' files in packages actually consist of.

My thinking is that at present, each package offers (or trys to) too much in terms of interface and page flow. I'd rather see packages offering more minimal interfaces, but organised as easily re-usable fragments. Offering therefore more scope to organise the package as yuo require....

10: External Authentication (response to 1)

Posted by nandha kumar on 12/26/06 10:34 AM

I want to develop a application in C++ / VC++ which will change openVMS system password,

I would really appreciate if any one could tell me the steps to achive this.

if any code available could send me .

Thanks and Regards
nandha