Re: LDAP and Single Sign On MORE THOUGHTS
| From: | Rick Emery | Date: | Fri, 10 Mar 2006 18:08:13 +0000 |
| Subject: | Re: LDAP and Single Sign On MORE THOUGHTS | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-231775@lists.php.net to get a copy of this message | ||
Quoting Jochem Maas <jochem@iamjochem.com>:
Rick Emery wrote:Okay. I don't know enough about encoding/encryption to discuss the merits either way, but I'll go along with your suggestion. So to carry through on my thought, the "secret prefix" would have to be constant. I'd like to find a way to make it variable (and random, even; I'm working under the assumption that at least one of our users would be smart enough to write a cookie to masquerade as another user). I have an idea, but I have little experience with Active Directory or LDAP, and I think I'm venturing into the space of "off-topic". I wonder if it would be possible (probably after modifying the schema) to write a value into the user's account in Active Directory/LDAP. The login script could generate a random string to prefix the username, hash it, write the random value into the user's LDAP record, and write the cookie. The PHP app on the other side could get the value from the user's LDAP record and then do the comparison. That way, each user would have a different "secret prefix", and it would be different each time that user logged in. Thoughts?Okay, I'm following all of this. So I could take, say, the username reversed and encode it, then decode it in the PHP application, and beI wouldn't do it like that.... instead stick the username in the cookie in plaintext and as a oneway encoded hash (the hash creation could make use of a fixed, secret prefix string [amongst other things) to make it secure] - then to check the cookie you take the plain text name perform the same hash creation routine on it and compared the results of that with the encoded hash that was sent in the cookie - if they match the cookie could be considered valid and untampered. the basic jist being don't use two way encryption, use a oneway hash like sha1().
well you can stick it in the session ... but like I said decoding is an unnecessary step it seems to me (given that you can achieve the validation using a oneway encryption method)Wouldn't the session expire on completion of the login script? If I opened a browser to run an application on our Intranet, wouldn't that create a different session? Again, I may be missing something. Thanks for the discussion; I'm really enjoying it. Rick