This is good. I didn't know whether you were relying on the web server/domain to authenticate the user or if you were using some vb command to read the username.
Axton Grams On 10/26/06, Heider, Stephen <[EMAIL PROTECTED]> wrote:
Axton, Great questions. I tested each of these scenarios. I created a local account with a username of an existing employee. After some testing I then added this user to the local Admin group and also added the employee's domain\username to the local Admin group. Local accounts do not have access to connect to our remedy web server, only authenticated domain users. With each attempt the Windows login prompt was presented. When I provided my network credentials the web app knew that I was using my login name and not the local user. I then attempted to Run As IE as the local account user (logged into Windows as me) and entered the URL in the address field. The web app knew it was me. I then logged into Windows as the local account and ran IE with Run As me. Same result. The web app checks the domain when logging in. All our employees are in the same domain, so checking here is easy. For companies that have multiple domains additional checks would need to be done. You could also track a lot of details regarding the SSO web app session, such as IP address, computer name, etc. If someone successfully spoofed a login [to get into Remedy only] in the logging file/table tracks could lead back to the culprit. The only thing I didn't try was to rename my computer to the name of the domain. This may present the web app with domain\username, however the Remedy web server still wouldn't allow access without a valid domain account login. To spoof the web app I think that either the browser or .Net libraries would need to be hacked. Or, if they somehow intercepted calls made to HttpContext.Current.User.Identity.Name from the web app and interjected a new value when sending data back to the web server it might work. Can't say for sure, but if someone can hack into this they may also be able to hack into LDAP authentication as well. Stephen -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, October 26, 2006 11:52 AM To: [email protected] Subject: Re: Client Application SSO (U) 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
