Re: Client Application SSO (U)
This is probably true for some browsers. Seems that some do not store https info in browser history, though I do not know of a standard that would prevent this and I would not expect all browsers to act the same. All in all, it's not a secure method to pass credentials that should otherwise be private. Axtno Grams On 10/30/06, Michiel Beijen <[EMAIL PROTECTED]> wrote: 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: 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? > > >
Re: Client Application SSO (U)
Dylan, The Remedy SSO interface requires additional configuration and programming on mid tier. From what I have read (here and elsewhere) and conversations I've had this is not trivial. Two mid tier-specific products I reviewed cost $15K - $20K for SSO, plus annual support. The SSO interface in mid tier is not an out-of-the-box implementation - although it should be. If you have a quick and easy solution for mid tier SSO, please let us know how you got it to work and your environment. My mid tier environment: ARS 6.3 Windows Server 2003 IIS 6 ServletExec 5.0 Regarding SSO for the Windows User Tool, you can set it to cache your Remedy password. In many organizations this is considered a security risk that is too high. I have previously researched developing an SSO solution for WUT. It's on hold for now as there are other projects I need to work on. I plan to get back to the SSO for WUT project in a few months. Stephen -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dylan Thomas Sent: Thursday, October 26, 2006 11:45 AM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) Stephen, I'm just curious why you couldn't use the Remedy SSO implementation? That's what we're using here and no probs so far. I'm also confused about the User tool SSO. If you uncheck the prompt for password box, it'll auto log you in? Are you talking about making it so you can login to any workstation on the network, open the User tool and it will auto log you in? Now that would be cool :) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Client Application SSO (U)
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: 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
Re: Client Application SSO (U)
Stephen, I'm just curious why you couldn't use the Remedy SSO implementation? That's what we're using here and no probs so far. I'm also confused about the User tool SSO. If you uncheck the prompt for password box, it'll auto log you in? Are you talking about making it so you can login to any workstation on the network, open the User tool and it will auto log you in? Now that would be cool :) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Client Application SSO (U)
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: 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 o
Re: Client Application SSO (U)
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. > > > >
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 aut
Re: Client Application SSO (U)
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
Re: Client Application SSO (U)
** Patrick: Want to fill me in with the gruesome details and provide the code? We are still looking for a SSO solution for the Army's Remedy servers. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of patrick zandiSent: Thursday, October 26, 2006 7:54 AMTo: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U) ** Correct.. I did what he did on the Solaris servers.. Back in March / April time frame.. We did something similar to Stephen.. On 10/26/06, McKenzie, James J C-E LCMC HQISEC/L3 <[EMAIL PROTECTED]> wrote: ** Patrick: Again, this looks like a Windows only solution, which will not work for the Army's Remedy servers on a large scale as they are installed on UNIX systems. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of patrick zandi Sent: Thursday, October 26, 2006 6:24 AM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** The Remedy SSO Solution would work in your Case Stephen, except.. you do not need all your users in the user form. I have that working fine in your Endowment.. I am trying to work with Remedy and the USERTOOL however.. The only Guy that does this.. it doing this of his OWN will and on his OWN time... which I find very Strange from a Support Prospective. The file example they game me.. will not even compile in Visual Studio 2005. I am not a Coder.. and am not a guy who just goes and Creates my own DLL's all the time. so I am Stuck.. But it apparently worked for Remedy at one time.. or another. On 10/26/06, Heider, Stephen <[EMAIL PROTECTED]> wrote: For inquiring minds... here is the SSO solution I implemented here. [Windows only solution removed] __20060125___This posting was submitted with HTML in it___ -- Patrick Zandi __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
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
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** James, The logic behind the approach should work fine on different platforms. I only use ASP/VB because of our environment and I am comfortable with the languages. This could be have been written in Java, for example, on a different platform. There are several external requirements needed to make this work: - Web programming language that supports one of the ARS APIs. - Web server needs to be able to communicate the username of the currently logged in network user to your SSO web application. I think almost all can do this. However, users coming from the internet might not work because capturing the network name could produce mixed results (ie. someone could spoof the username if they are not logged into your internal network). - A separate application (or even all in Remedy) that creates and stores the encrypted passwords. There are many encryption libraries available or you could create this yourself. - SSO application needs to decrypt the password. Everything else is just straight ARS. For example, embedding the username and password in the URL. HTH. I think if each of the four requirements listed above can be met then you could create this in a few days. If you have questions feel free to contact me on or off list. Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Thursday, October 26, 2006 10:21 AMTo: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U) ** Stephen: How hard do you think this would be to extend into the UNIX world? James McKenzie L-3 GSI -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Heider, Stephen Sent: Thursday, October 26, 2006 5:37 AM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) For inquiring minds... here is the SSO solution I implemented here. [Windows only solution removed] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
** Correct.. I did what he did on the Solaris servers.. Back in March / April time frame.. We did something similar to Stephen.. On 10/26/06, McKenzie, James J C-E LCMC HQISEC/L3 <[EMAIL PROTECTED]> wrote: ** Patrick: Again, this looks like a Windows only solution, which will not work for the Army's Remedy servers on a large scale as they are installed on UNIX systems. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of patrick zandi Sent: Thursday, October 26, 2006 6:24 AM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** The Remedy SSO Solution would work in your Case Stephen, except.. you do not need all your users in the user form. I have that working fine in your Endowment.. I am trying to work with Remedy and the USERTOOL however.. The only Guy that does this.. it doing this of his OWN will and on his OWN time... which I find very Strange from a Support Prospective. The file example they game me.. will not even compile in Visual Studio 2005. I am not a Coder.. and am not a guy who just goes and Creates my own DLL's all the time. so I am Stuck.. But it apparently worked for Remedy at one time.. or another. On 10/26/06, Heider, Stephen <[EMAIL PROTECTED]> wrote: For inquiring minds... here is the SSO solution I implemented here. [Windows only solution removed] __20060125___This posting was submitted with HTML in it___ -- Patrick Zandi __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Patrick: Again, this looks like a Windows only solution, which will not work for the Army's Remedy servers on a large scale as they are installed on UNIX systems. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of patrick zandi Sent: Thursday, October 26, 2006 6:24 AM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** The Remedy SSO Solution would work in your Case Stephen, except.. you do not need all your users in the user form. I have that working fine in your Endowment.. I am trying to work with Remedy and the USERTOOL however.. The only Guy that does this.. it doing this of his OWN will and on his OWN time... which I find very Strange from a Support Prospective. The file example they game me.. will not even compile in Visual Studio 2005. I am not a Coder.. and am not a guy who just goes and Creates my own DLL's all the time. so I am Stuck.. But it apparently worked for Remedy at one time.. or another. On 10/26/06, Heider, Stephen <[EMAIL PROTECTED]> wrote: For inquiring minds... here is the SSO solution I implemented here. [Windows only solution removed] __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Stephen: How hard do you think this would be to extend into the UNIX world? James McKenzie L-3 GSI -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Heider, Stephen Sent: Thursday, October 26, 2006 5:37 AM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) For inquiring minds... here is the SSO solution I implemented here. [Windows only solution removed] __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
list is stored in a text file that can be updated without recompiling the app). Now, all web applications loadquickly 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. Ispent a little time developing a .Net solution. I had to switch gearsbecause this was not an immediate requirement. What I did discoverafter 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 onprogramming global hooks. BTW, if anyone out there is an expert in .Nethook programming please contact me off list. Thanks.Stephen From: Action Request System discussion list(ARSList)[mailto:arslist@ARSLIST.ORG] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Wednesday, October 18, 2006 5:09 PMTo: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U)**Sandra:Don't be so greedy. Let Stephen share with everybody James McKenzieL-3 GSIInnovative Solutions - Extraordinary ResultsFrom: Action Request System discussion list(ARSList)[mailto: arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIOSent: Wednesday, October 18, 2006 1:56 PMTo: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U) **UNCLASSIFIEDSounds very interesting - we are investigating single login. Pleasecommunicate off user group. Thanks.Sandra HenniganOSD Remedy AdministratorOffice # 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: arslist@ARSLIST.ORG] 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 singlesign on now with the link below. The SSO application is presentlylocated on my computer but logs into the regular Client application on remedyweb. The SSO application only works for employees/agents who donot have a Remedy license... So we will need to test with other employeenumbers. 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 bythe SSO application - only the current Windows username will be used. Just change the employee or agent number to login as someoneelse.__20060125___This posting was submitted with HTML init__ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org-- Patrick Zandi __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
lso 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
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Most of the major vendors provide an SSO application. Oracle, IBM, BMC, and Citrix OEM their product from a company called Passlogix. This product includes support for most Web Based, Windows Based, and Host/Mainframe based applications. This product also supports shared workstation configurations, multifactor authentication, and user provisioning product integration. IBM also provides another application that provides SSO capability for Web Based applications only as well. Just my .02. If you want more details contact me offlist. Scott Scott HammonsPrincipal Consultant Advanced Integrated Solutions, Inc. www.aisconsulting.net Mobile: (210) 378-8229 From: Action Request System discussion list(ARSList) on behalf of McKenzie, James J C-E LCMC HQISEC/L3Sent: Wed 10/18/2006 16:36To: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U) ** Sandra: There are many in the DoD that would like a SSO solution as well as several in the private sector. This topic has been open for quite some time on the list. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 2:33 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** UNCLASSIFIED OK by me - Didn't know "everybody" would be interested. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant(tm) __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Actually, isn't there something out there for this? It strikes me as odd that the vendor, or some enterprising third-party VAR would not have developed this already > Isn't this how big government gets started. :-) > > Thad > "Argue for your limitations, and sure enough, they're yours."-- Richard > Bach > > > > "McKenzie, James J C-E LCMC HQISEC/L3" <[EMAIL PROTECTED]> > Sent by: "Action Request System discussion list(ARSList)" > > 10/18/2006 03:28 PM > Please respond to > arslist@ARSLIST.ORG > > > To > arslist@ARSLIST.ORG > cc > > Subject > Re: Client Application SSO (U) > > > > > > > ** > Dave: > > I agree. We need some sort of leadership to form and get the RUG up and > running. > > James McKenzie > > > From: Action Request System discussion list(ARSList) [ > mailto:[EMAIL PROTECTED] On Behalf Of Davis, David CTR NAVSURFWARCENDIV > Crane, Code 0552 > Sent: Wednesday, October 18, 2006 3:20 PM > To: arslist@ARSLIST.ORG > Subject: Re: Client Application SSO (U) > > ** > James, > > I don't have time right now (workload and all) but I feel DoD as a > community should be seriously looking to develop RUG due to our common > interests and concerns. > > Dave Davis > SAIC > __20060125___This posting was submitted with HTML in > it___ > > ***IMPORTANT NOTICE: This communication, including any attachment, > contains information that may be confidential or privileged, and is > intended solely for the entity or individual to whom it is addressed. If > you are not the intended recipient, you should delete this message and are > hereby notified that any disclosure, copying, or distribution of this > message is strictly prohibited. Nothing in this email, including any > attachment, is intended to be a legally binding signature.*** > > ___ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Client Application SSO (U)
** Isn't this how big government gets started. :-) Thad "Argue for your limitations, and sure enough, they're yours."-- Richard Bach "McKenzie, James J C-E LCMC HQISEC/L3" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 10/18/2006 03:28 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Client Application SSO (U) ** Dave: I agree. We need some sort of leadership to form and get the RUG up and running. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 Sent: Wednesday, October 18, 2006 3:20 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** James, I don't have time right now (workload and all) but I feel DoD as a community should be seriously looking to develop RUG due to our common interests and concerns. Dave Davis SAIC __20060125___This posting was submitted with HTML in it___ ***IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.*** __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Dave: I agree. We need some sort of leadership to form and get the RUG up and running. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 Sent: Wednesday, October 18, 2006 3:20 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** James, I don't have time right now (workload and all) but I feel DoD as a community should be seriously looking to develop RUG due to our common interests and concerns. Dave Davis SAIC __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** James, I don't have time right now (workload and all) but I feel DoD as a community should be seriously looking to develop RUG due to our common interests and concerns. Dave Davis SAIC From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Wednesday, October 18, 2006 16:43To: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U) ** Dave: Not that I know of. I could check with the folks at the Army Knowledge On-Line to see if there is an Army group. You wanna be the 'boss'? James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 Sent: Wednesday, October 18, 2006 2:41 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** Hello James, Since you mentioned it, DoD, is there a DoD-wide user's group out there and If not who is interested in creating one? Later, Dave Davis __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: Message ** Hi Sandra, I'm slow at getting to my email ;-) Later, Dave From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Hennigan, Sandra H CTR OSD-CIOSent: Wednesday, October 18, 2006 16:41To: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U) ** UNCLASSIFIED Odd that I was the only one that asked for more info. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant™ 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 McKenzie, James J C-E LCMC HQISEC/L3Sent: Wednesday, October 18, 2006 5:36 PMTo: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U)** Sandra: There are many in the DoD that would like a SSO solution as well as several in the private sector. This topic has been open for quite some time on the list. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 2:33 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** UNCLASSIFIED OK by me - Didn't know "everybody" would be interested. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant(tm) __20060125___This posting was submitted with HTML in it_20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Sandra: I know there is a lot of Remedy usage throughout the DoD and not just as a Trouble Management System. I think that 'we' need a RUG specific to the DoD audience where we can discuss issues specific to the use of Remedy ARS within our community. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 2:46 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** UNCLASSIFIED I've been working to get one going here at the Pentagon user's group; not DoD wide but a start. Remedy is VERY interested and has been a lot of help. 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:arslist@ARSLIST.ORG] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3 Sent: Wednesday, October 18, 2006 5:43 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** Dave: Not that I know of. I could check with the folks at the Army Knowledge On-Line to see if there is an Army group. You wanna be the 'boss'? James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 Sent: Wednesday, October 18, 2006 2:41 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** Hello James, Since you mentioned it, DoD, is there a DoD-wide user's group out there and If not who is interested in creating one? Later, Dave Davis __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: Message ** UNCLASSIFIED I've been working to get one going here at the Pentagon user's group; not DoD wide but a start. Remedy is VERY interested and has been a lot of help. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant™ 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 McKenzie, James J C-E LCMC HQISEC/L3Sent: Wednesday, October 18, 2006 5:43 PMTo: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U)** Dave: Not that I know of. I could check with the folks at the Army Knowledge On-Line to see if there is an Army group. You wanna be the 'boss'? James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 Sent: Wednesday, October 18, 2006 2:41 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** Hello James, Since you mentioned it, DoD, is there a DoD-wide user's group out there and If not who is interested in creating one? Later, Dave Davis __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Sandra: This must be a first. I've been asking all over for a SSO solution for quite some time based on smart card PKI and/or Windows AD authenication. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 2:41 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** UNCLASSIFIED Odd that I was the only one that asked for more info. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant(tm) __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Dave: Not that I know of. I could check with the folks at the Army Knowledge On-Line to see if there is an Army group. You wanna be the 'boss'? James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 Sent: Wednesday, October 18, 2006 2:41 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** Hello James, Since you mentioned it, DoD, is there a DoD-wide user's group out there and If not who is interested in creating one? Later, Dave Davis __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: Message ** UNCLASSIFIED Odd that I was the only one that asked for more info. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant™ 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 McKenzie, James J C-E LCMC HQISEC/L3Sent: Wednesday, October 18, 2006 5:36 PMTo: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U)** Sandra: There are many in the DoD that would like a SSO solution as well as several in the private sector. This topic has been open for quite some time on the list. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 2:33 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** UNCLASSIFIED OK by me - Didn't know "everybody" would be interested. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant(tm) __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Hello James, Since you mentioned it, DoD, is there a DoD-wide user's group out there and If not who is interested in creating one? Later, Dave Davis From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Wednesday, October 18, 2006 16:36To: arslist@ARSLIST.ORGSubject: Re: Client Application SSO (U) ** Sandra: There are many in the DoD that would like a SSO solution as well as several in the private sector. This topic has been open for quite some time on the list. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 2:33 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** UNCLASSIFIED OK by me - Didn't know "everybody" would be interested. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant(tm) __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: RE: Client Application SSO (U) ** Sandra: There are many in the DoD that would like a SSO solution as well as several in the private sector. This topic has been open for quite some time on the list. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Wednesday, October 18, 2006 2:33 PM To: arslist@ARSLIST.ORG Subject: Re: Client Application SSO (U) ** UNCLASSIFIED OK by me - Didn't know "everybody" would be interested. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant(tm) __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: Message ** UNCLASSIFIED OK by me - Didn't know "everybody" would be interested. Sandra Hennigan OSD Remedy Administrator Office # 703-602-2525 x251 CACI - Ever Vigilant™ 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 McKenzie, James J C-E LCMC HQISEC/L3Sent: Wednesday, October 18, 2006 5:09 PMTo: arslist@ARSLIST.ORGSubject: 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:arslist@ARSLIST.ORG] 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:arslist@ARSLIST.ORG] 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___ __20060125___This posting was submitted with HTML in it___
Re: Client Application SSO (U)
Title: 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:arslist@ARSLIST.ORG] 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:arslist@ARSLIST.ORG] 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___
Re: Client Application SSO (U)
Title: Message ** 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™ 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, StephenSent: Wednesday, October 18, 2006 4:50 PMTo: arslist@ARSLIST.ORGSubject: 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. http://tpa9pn0321/ARS_SSO/Default.aspx?User=14293 Let me know if you have any questions. Stephen Heider Remedy Administrator/Developer PBS&J Tampa Technology Operations - ADG5300 West Cypress Street Tampa, FL 33607 813.281.7329 [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
