I've been thinking on this for some time...  


In the past, we put the username/password into a database (properly encrypted of course), and checked login's against that table.  However it quickly became an issue where each application had it's own login system.  My thoughts on this are to create an authentication web service.  Depending on the environment/requirements, permissions can be handled by the applications in question, or by an application for managing the logins.  


For instance, an HR supervisor may need to create a user account for a new employee.  They would open the GUI interface that calls the appropriate routines from the authentication web service to create a new user account.  The question is where do the permissions for the user get stored.  If the HR supervisor only had access to an HR application, then that application might be used to match the user account to the permissions needed for the app.  However if the HR Supervisor was responsible for assigning permissions to ALL internal applications, then it makes more sense to store those permissions in the authentication web service.


I think the storage of permissions will come down to a judgement call for each organization, but by at least moving the authentication into a web service will allow that magical "single login".  Microsoft tried to do something like this with Passport, but failed - mostly because the storage of the authentication information should be kept at an organizational level, not a global level by a for-profit company which has a number of trust issues.


My thoughts....


Shawn

-----Original Message-----
From: George Abraham [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 9:28 AM
To: CF-Talk
Subject: login methods

Hi all,
Rick Root's statement that he doesn't see the point of a cflogin tag
for applications made me think of this. What login methods/processes
do most people use? OK, that's too generic a question! In a
multi-environment situation (where people from different organizations
have to use the same application), what are the principles you use to
log people in? And keep in mind that people from different
organizations also have to have access to other different applications
using the same individual login.

So far as I can see, only something like Shibboleth
(http://shibboleth.internet2.edu/) really solves this problem, at
least for me, from an educational/research institution perspective.
Has anybody used this type of distributed authentication system?

Now this sounds like a really rambling post!

George
  _____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to