The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

LDAP and single sign on

hi all,
  we have a web application where in users can log in and take a look at their personal information, update it etc...their credentials are stored in our database and when they try to log in, it is looked up against this database.

at the same time, all users data is encrytped using their login name and password..and few other variables also.

now we have a new big customer, who has LDAP in their organization. they want our application to be a single sign on against their LDAP. i read about basics of LDAP, read about single sign one etc.. but lot of things are not so clear. these are few things, if some one could give simple explanation.

1. i am assuming, by single sign on, there is no need to create accounts in our application. all the authentication will be done against the LDAP. so that means there is no need to store user accounts in our application.
2. once the authentication is verified, the page will forward to our application and they will be use it as usual.
3. since we use user name / password to encrypt data, do we have to use LDAP credentials to encrytpion?

is this the right concept? or am i missing some thing?

thank you
dan
dan
Tuesday, June 06, 2006
 
 
1. LDAP will authenticate a user, that is, verify that the user is who he says he is.

It will not however authorize a user, that is, grant privileges based upon the user's identity (well, technically it does, but those are usually operating system type of priviledges).

Since you keep additional personal information and allow them to view and edit it, you will still want to keep the concept of accounts. You would just assume that if my cookie or session id says I'm TheDavid, then I should have read/write access to my info.  However, if my id says I'm JoeBob, then I should only have read access to TheDavid's files.

2. Yes and no. Depending on how its configured, LDAP will forward the cookie, session id or whatever to the web server. The server and/or your application is still responsible for returning web pages, including "unauthorized" error messages.

3. Yes. LDAP essentially replaces your username/password verification component.
TheDavid
Tuesday, June 06, 2006
 
 
There are options/strategies around to do role-based application "level" and "access" rights per user using LDAP as well.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetserv/html/azmandynamgrps.asp
Glen Hamer
Tuesday, June 06, 2006
 
 
What happens to your encryption if a user changes their password? Just curious.
ping?
Wednesday, June 07, 2006
 
 
User passwords are independent of the encryption used - the LDAP software has the necessary passkeys to encrypt your user name and password before transmitting them.
TheDavid
Wednesday, June 07, 2006
 
 
I believe ping was referring to #3 they use user name / password to encrypt data.  If they are really using the password for encryption of stored data, then changing it has interesting ramifications.  Most security people would balk at providing an application the user's LDAP password.
MSHack Send private email
Wednesday, June 07, 2006
 
 
Oh.

The thought didn't occur to me that they would encrypt the data itself using the user name and password. I can imagine encrypting the entire database with a vendor defined key. It is also (obviously) possible to require that user name and password hashes match before allowing access to the data.

But literally encrypting a record with that person's user name and password is a very bad idea regardless of whether LDAP is involved or not.

The common example: company policy forces the user to change the password, user picks an eight digit alphanumeric string as recommended and forgets it. In the first two scenarios that I mentioned, you can just blow away the user password and have him recreate it. In the third scenario, he either has to recreate all of his data or you have to literally break the encryption for it to be useful again.
TheDavid
Wednesday, June 07, 2006
 
 
I wouldn't normally respond but, right now, I'm working on something similar to this.  Mind you, I'm not an expert so I'm just relaying my imperfect understanding.

1. i am assuming, by single sign on, there is no need to create accounts in our application. all the authentication will be done against the LDAP. so that means there is no need to store user accounts in our application.

To access the LDAP info, LDAP has a simple user name and password scheme.  However, some companies leave LDAP open (or only have one user name and password) so apps can easily access it.

Then, for each user entry, they "attach" a user name and encrypted password.  (I'm getting the terminology all wrong, I'm sure.)  So, apps get the user name from the user, look up the corresponding LDAP entry, get the encrypted password, encrypt the given password from the user and compare the newly encrypted password to the one stored in LDAP.

So, yes, *you* don't need to create accounts as long as *somebody* is maintaining the LDAP installation.  And, yes, it's "single sign on" because each user only has to remember one password, even though he may have to put that same password in multiple times.  (More like "single password", than "single sign on", in my opinion.)

2. once the authentication is verified, the page will forward to our application and they will be use it as usual.

You write the code to do this.  LDAP only provides the encrypted password; you do all the encryption, comparison, retry, sorry, redirects and everything else.

It'd be nice if it was automatic, like how you describe.

3. since we use user name / password to encrypt data, do we have to use LDAP credentials to encrytpion?

I don't quite understand the question but I think that you keep a copy of the unencrypted password from when the user logs in and then encrypt your data with it.  But I'm probably not smart enough to answer this question correctly.
Daniel Howard Send private email
Wednesday, June 07, 2006
 
 
thank you for all the great information.

i was under the wrong impression about using username and password to encrypt. i am not the actual developer, just helping out in technology issues.

we are generating an auto key associateed with that user and we use that to encrypt the data. and also, some other data that will not change for the user.

today we had a small discussion with the other team. and the idea is that they have a portal, and the users log on to the portal(LDAP) and they should see a link to our app , which will not require a log in. it seems in all the probability, we both will agree on some user specific data, such as id that is unique to the user, that will be passed to our app when they move from their portal to our portal. and this id will be used in encrytpion. of course we will have to manage the session also, so that they can return back to their portal if user desires.

thanks
dan

Wednesday, June 07, 2006
 
 
I'm not sure if I'm interpreting your questions correctly or not. However, it's fairly easy to use LDAP as an authentication to another app. Just have your app get the userid/password and use those to bind to the LDAP server. If the bind fails, then the password is incorrect. If the bind is successful, then the login/password was correct.
Developer #13
Saturday, June 10, 2006
 
 
If they are doing LDAP SSO they are probably using a authorization package like Siteminder/Tivoli Access Manager/etc.
Duff Send private email
Friday, June 16, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz