CSS? On Thu, Jan 7, 2010 at 1:51 PM, Zaphod Beeblebrox <[email protected]> wrote: > > I guess one of my main concerns is keeping users from feeling > disconnected...most of my sites have a different look and feel about > them. The sso login page looks different from all the other > sites.....how have you guys approached this? > > On Thu, Jan 7, 2010 at 10:50 AM, Justin Scott > <[email protected]> wrote: >> >>> I've implemented a single authentication source for my web apps, >>> but each app still has it's own login form, password change form, >>> etc. Those of you who have a sso setup, do you redirect users to >>> a completely different web site to login in? >> >> What I've done in the past is pick one place where credentials are managed >> and leave that as the only place where the password can be changed, reset, >> etc. All logins are run through a login page on that site as well for >> authentication. >> >> If the user tries to access a resource on another site which requires auth, >> they get redirected to the central login page on the auth site with a URL >> variable that says what URL they were trying to access originally. This >> gets passed through along with the login process. The login form takes >> their username and password and does normal authentication. Once they're >> verified, a cookie is set (on the auth site so they don't need to login >> again) and they get redirected back to the original URL along with another >> variable appended (i.e. http://www.example.com/members/?auth={authinfo}). >> >> The auth variable is a base-64 encoded value which contains the following >> info: their member ID, username, or whatever identifying information is >> needed, a timestamp, and a salted hash of that ID information combined with >> the timestamp. The receiving site has code built into the >> application.cfm/cfc which looks for this auth URL variable and, if found, >> decodes, recombines and rehashes the ID and timestamp, compares against the >> hash sent in, and if valid, checks that the timestamp is within 5 minutes >> (prevents the URL from being saved and re-used). If everything checks out, >> the receiving site can assume that the user is authenticated and sets >> whatever session variables or cookies are needed as though they had logged >> in locally. The only information that really needs to be kept secret is the >> salt for the verification hash between the two sites to keep it secure. >> >> If the user then goes to another site which requires auth, they get >> redirected back to the auth site which then sees the session variable or >> cookie from the previous login, assumes they are logged in, and constructs a >> new redirection auth value and sends them back to where they just came from, >> which then sees the auth URL value, decodes, verifies, etc. >> >> The user logs in once and can then move freely among resources on any web >> site which understands and works with the authentication site. The sites >> don't have to be on the same server, or even on the same network or share >> database information in any way (though they could, of course). >> >> The code isn't really all that complex once you wrap your head around it. >> I've implemented this in a few places without any problems to date. >> >> >> -Justin Scott >> >> >> >> > >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-community/message.cfm/messageid:310069 Subscription: http://www.houseoffusion.com/groups/cf-community/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.5
