So what happens if I create a local account on my desktop that has the same login name as some other domain account, then proceed to access your SSO enabled web interfaces?
Or even better, create the local account, then run iexplore.exe as that user? Axton Grams On 10/26/06, Heider, Stephen <[EMAIL PROTECTED]> wrote:
For inquiring minds... here is the SSO solution I implemented here. Background: Over the last couple months I have been researching SSO solutions for Remedy, initially only for Mid Tier (6.3, 7.0). There are several good ones that will do the job. The costs prevented us purchasing ($15K for a Mid Tier-only solution up to $100K+ for a solution for all web and Windows applications including non-Remedy apps). A few weeks after the decision was made not to purchase I began reading more and more posts about implementing SSO. I gleaned some ideas from Listers and determined that I was going to find a solution. It didn't take long to see that this would work. It may not be applicable in certain companies/organizations (ie. top secret government work), but I suppose it could be useful in about 90% of Remedy installations. Goal: Provide seamless login (aka SSO) to our end-user Mid Tier application for all employees with Read/Read Restricted licenses. We wanted to make it easy for our employees to be able to submit and view their own tickets. SSO makes it as simple as clicking a link on a web page. For those with Fixed/Floating licenses (technicians and technical management) it was deemed acceptable to continue having them enter their network password to login to the Remedy Windows application. Benefits: Employees only need to click a link on our intranet to login. It's quick - takes about 1/2 second extra to perform the automated login process. No changes needed on Mid Tier. No changes needed for any forms used by the Mid Tier application. Limitations: Users with SSO login will no longer be able to login to the Windows User Tool. This is not an issue here as only Fixed/Floating license users have the Windows User Tool installed. It is only approximately 99.9% as secure as using LDAP. It can be made more secure with additional programming but for our purposes it is more than adequate. Requirements: All employees must have a record in the User form. Cross-Ref Blank Password must be enabled. LDAP/AREA authentication must be enabled. LDAP/AREA authentication is not used for SSO - instead internal Remedy passwords. The username of the currently logged in network user must be accessible to the web application. We run Windows XP on the clients and Windows Server 2003/IIS on the server (Anonymous access disabled and Integrated Windows Authentication enabled). How it Works: I added one character field to the User form to hold an encrypted password. For each Read/Read Restricted user I generate a separate GUID and store it in the regular Password field, and also an encrypted copy of the new password in the new SSO Password field. When the web application runs it captures the current network username, retrieves the encrypted password from the User form, decrypts the password, formats a URL containing the username and password, then finally redirects the web page to the new URL. User is logged in. The password does not appear in the Browser Address field (or if it does, it's only displayed for 1/4 second). If the employee that clicked the link has a Fixed/Floating license then the web page is redirected to the standard web login page. Security: No-one with direct access to the User form, either in Remedy or at the DB, can use the encrypted password. The encryption/decryption key is stored "somewhere" on the server. There are numerous methods and locations for storing and retrieving encrypted encryption/decryption keys. With the Windows and .Net cryptography APIs a key could actually be generated and not known by any human, even the Remedy Administrator. The encrypted passwords in the User form can be scheduled to be automatically changed every night. So even if an employee was able to discover their Remedy password it would only be good for one day. The users don't know or need to know what their password is, as long as it matches what Remedy has. Technologies Used: ASP.Net 2.0 VB.Net 2005 Related Stuff: Because the initial caching of Remedy forms (in this case the end-user application) takes a long time, I wrote a .Net app that pre-caches all forms used by the end-user and technician applications. The app is scheduled to run each morning on the Mid Tier server - it first runs IISReset (forces Mid Tier to clear its cache), then proceeds to load each form in a list of forms (list is stored in a text file that can be updated without recompiling the app). Now, all web applications load quickly as each form is freshly cached each morning. What's Next: SSO for the Windows User Tool. A couple of months ago I looked into creating an application that provides SSO functionality for WUT. I spent a little time developing a .Net solution. I had to switch gears because this was not an immediate requirement. What I did discover after experimenting is that I am about 90% sure it can be accomplished. I hope to pick this back up in a few months. I also need to brush up on programming global hooks. BTW, if anyone out there is an expert in .Net hook programming please contact me off list. Thanks. Stephen ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3 Sent: Wednesday, October 18, 2006 5:09 PM To: [email protected] Subject: Re: Client Application SSO (U) ** Sandra: Don't be so greedy. Let Stephen share with everybody.... James McKenzie L-3 GSI Innovative Solutions - Extraordinary Results ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 1:56 PM To: [email protected] Subject: Re: Client Application SSO (U) ** UNCLASSIFIED Sounds very interesting - we are investigating single login. Please communicate off user group. Thanks. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant(tm) Apparently, there is nothing that cannot happen today. Mark Twain -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, Stephen Sent: Wednesday, October 18, 2006 4:50 PM To: [email protected] Subject: Client Application SSO ** The development is just about complete. You can test the single sign on now with the link below. The SSO application is presently located on my computer but logs into the regular Client application on remedyweb. The SSO application only works for employees/agents who do not have a Remedy license... So we will need to test with other employee numbers. For our testing (only) you can pass in one parameter - User. This simulates that person being logged into Windows on your computer. Obviously when deployed to production no parameters will be processed by the SSO application - only the current Windows username will be used. Just change the employee or agent number to login as someone else. __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
