Axton, This will also be true for https right? With https the TRAFFIC is encrypted but the URLs are not. This makes sense because you first have to request a site (by issuing an URL) before the secure connection can be set up.
Kind regards, Michiel On 10/26/06, Axton <[EMAIL PROTECTED]> wrote:
The only other things I can think of: If not using https - browser will store url in history (username/pass) - proxy server will store url (username/pass) - username/password are visible on network in plain text Axton Grams On 10/26/06, Heider, Stephen <[EMAIL PROTECTED]> wrote: > 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: [email protected] > 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: [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 > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are", sponsored by: www.wwrug.org _______________________________________________________________________________
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
