If you can find a way to bypass the security with this model please post a message. I can then patch it. Thanks.
Stephen -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, October 26, 2006 3:09 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) 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: arslist@ARSLIST.ORG > 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: arslist@ARSLIST.ORG > > 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: arslist@ARSLIST.ORG > > 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: arslist@ARSLIST.ORG > > 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
