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.
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:arslist@ARSLIST.ORG] 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: 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___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
--
Patrick Zandi __20060125_______________________This posting was submitted with HTML in it___
