> -----Original Message----- > From: Cynthia Reece [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 13, 2005 11:42 AM > To: CF-Talk > Subject: RE: Discuss: Cross Site Sign-on > > We have a central database schema that holds the user/role information > for a the applications.
For simple cross-site security we use SiteMinder (designed to do this specifically). An agent is installed on each "friendly" web server and these agents reference a central credential/entitlement repository. It's slightly cumbersome, but works at the web server level (and so protects any type of file and any application server) and does seem to do the job well enough. > What I would like to know is how to we allow these people to log-on in > one place and essentiall carry those credentials over to our other > domains as they move between our sites. The domains reside on different > servers and I am not sure how best to pass this information around. We've built a system for doing this kind of thing called "Cross Application Trust". In our case the system is primarily to allow aliasing across multiple applications. For example our Customer Service application allows the CS Reps to access the Agent system AS AN agent (to see what they see) and the Agent system allows access to the customer system AS A customer (again to allow an agent to see what they see). Out Cross App Trust system maintains this identity chain and allows any application to interrogate the "real" identity of the user easily. For example the Customer System allows the customer to change an address - but it won't allow an agent masquerading as a customer to do this. For our system each application is assigned a unique short name (for example "CSR", "AGTV", "CUST") that's used to identify it across all the participating applications. Each application defines a list of variables that it will return for a user. Our CS Reps return a numeric ID and a numeric location code; our Agents return a numeric Agent ID, a numeric Agency ID and a Boolean "General Agent" value. Each application defines these variables an publishes someplace publically accessible an XML list of "assertions" about the information it will provide to other apps. In effect its saying "I promise when I call you I'll provide this information in this format or you can ignore me". Because of this all data validation and typing is done up front and the member applications only have to check this stuff once (a member app will always know that "Agent ID" exists and is numeric). When going to another app the system packages up the current credentials and its assertion URL (and any upstream credentials) into a "stack" of credentials - the system to which the user first authenticated is always the top of the stack, the system the user is currently on is always the bottom. By traversing the stack you can determine the path the user took to get to the current system. The current system may add some information (for example the Agent ID) for the next system which is a request to masquerade as that user. This stack is encrypted using a shared key and passed to the next app. +) The next app attempts to decrypt the stack (if it can't the transfer fails). +) If a request for masquerading was made the current system tests the information passed (checks to make sure it's a valid Agent ID for example) and adds any additional information (like Agency ID and the General Agent Flag) to it. +) Finally the app checks the assertions for all of the apps in the stack (including itself). If any of the assertion testing fails (or if the app doesn't have the needed assertions cached already) the app will use the assertion URL to see if updated assertions are available and retest. If, after that something still fails the transfer fails. If everything succeeds the stack is kept in the new app for reference. It may then be appended to later to go to another app. I know it sounds complex, and it can be, but there are several very simple aspects to it: 1) Actual security of the system is centered almost exclusively on the encryption/decryption of the stack. So key management becomes your major headache. In effect you're allowing a "passwordless login" so you really need some way to determine that this is a "friend" and shared-key encryption is a pretty good way of doing that. 2) The whole assertion definition and management piece of this is really only support multiple types of user information - it can be eliminated if your identification information is simpler. 3) All of the complexity of the system is contained in abstracted "black box" components: all your participating systems need to know is how to access the stack. We've implemented this whole mess in CF 4.5 (the enterprise won't upgrade) using nested custom tags as a pseudo object model, but it would be even easier in CF MX+ using CFCs. The whole thing is several years old now (but still works a treat) - in a modern implementation I'd see the use of standardized web services for assertion management. In our case we defined an assertion format such that you could build the system using any language - nothing that the system does requires CF (although we've only even built CF clients for it). Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:202627 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
