Subscribe Now!
PeopleSoft Single Signon
(Sept. 20 update: since writing this we have created a Desktop Single Signon snap-on product that works with PeopleSoft Enterprise. Here's the announcement and here is the product page).
Single signon is widely desired, yet not widely understood. As usual with PeopleSoft, there isn't one simple answer, but the good news is that it's not that hard to get what you want. The biggest challenges are political rather than technical.
So, let's start by listing a few of the different common definitions of single signon. What most people mean (and want) is that a user signs on once in the morning and is then granted access to all other applications based on that signon. No additional login screens, etc.
Another common definition is that there is only one place for a user to authenticate with. No need to remember 17 different passwords from systems that have different rules about how often to change the password and how long it has to be. The drawback here is that the user still has to authenticate for each system that they access. I'll refer to this style as "single password".
Note that I use the word "authenticate" rather than saying "fill in their username and password". Although most environments are based on username and passwords, the best run environments go beyond just username/password in order to validate the user (think SecureID token).
One interesting wrinkle to all of this is somewhat PeopleSoft specific. PeopleSoft supports a notion of single signon between PeopleSoft instances.
If you have PeopleSoft HR, Financials, CRM, and EPM, then you actually have four different environments, not just four different product lines in one environment. There are some advantages to this loosely coupled model, but unified administration wasn't one of them. We actually made some progress at this at PeopleSoft towards the end, but it still never got to be as simple as administering one large system.
Given those four separate environments, PeopleSoft supported single signon between them. If a user logged into, say, Financials and then followed a link to the HR system they would not have to signon again. You do need to configure each system to trust each other (you don't want someone with access to a demo CRM system to be able to access your production Financials), but that is not difficult at all. PeopleBooks has good information on how to do this.
Note that the word LDAP has not yet been mentioned. LDAP is just a common place for storing user information (such as their password, their email address, etc.). By itself, it doesn't provide single signon. It only simplifies getting single signon working by having a standards-based common location for storing user credentials.
We made some big bets on LDAP support in PeopleSoft 8. When that came out back in 2000, there weren't really too many enterprise application vendors that supported LDAP. Of course, all of our customers in Higher Education had been telling us to do this for years (especially the University of Michigan). We even had fantasies about dropping our internal authentication support and using LDAP as the out of the box authentication mechanism for PeopleTools 9.
One problem that we had though was that when our field was trying to explain to other customers how this stuff worked, that the concept of single signon and LDAP got confused. Even to the point where the single signon section in PeopleBooks had to be changed to explain that they are not the same thing.
So, out of the box, you can get support for "single password" from the desktop level if your desktop signon uses a backend that supports LDAP (such as Microsoft Active Directory). The first time that the user accesses PeopleSoft they get prompted for their password again, but then (via the PeopleSoft single signon) the user can access all of your PeopleSoft systems.
If you want to go beyond this and have desktop level single signon, then you'll need to do some customization. A common way of doing this is to have a Windows server running IIS that acts as a proxy server to PeopleSoft. You setup IIS to use NTLM authentication for the proxy link, which will cause Internet Explorer to send in the user's desktop signon information. Then you create a little bit of signon PeopleCode that will check the custom HTTP header that IIS will attach to the request with the user's domain and login ID.
If you do this make ABSOLUTELY sure that you validate requests with this header come through the IIS server. Otherwise you've just opened up access to your entire PeopleSoft system to anyone that knows how to create an HTTP request with a custom header (which is painfully easy). This is because the IIS server just passes back the domain and username, but does not cryptographically secure it.
The nice thing is that this is not just limited to Internet Explorer. Recent versions of Mozilla based browsers (Mozilla 1.6+, Netscape 7.2+, Firefox 0.8+) also have support for Microsoft's NTLM protocol. If the user is on a different platform than Windows, then their desktop signon won't be passed along, but at least they won't be locked out.
If you want to do this type of Windows desktop single signon, but don't want/can't have an IIS proxy server, then you'll want to look at using jCIFS for that.
How about if you don't want to use the Windows login as the basis for desktop single signon. Is that even possible with PeopleSoft applications?
Sure. It takes a little bit more work, but it's possible. You'd have to install something locally on the client machine that get the user's credentials once, and then passes that along to somewhere where the PeopleSoft server can validate it. Either by passing it along in the browser headers or some other way. If you're interested in this, take a look at Steve Friedl's Illustrated Guide to SSH Forwarding. Using SSH as a mechanism for desktop single signon for PeopleSoft applications strikes me as an interesting idea.
Well, there's more to be said on this topic, but this has been sitting in the queue for too long, so I'm publishing what I've got. Please comment if you're interested in hearing more (as well as what you'd like to hear).
posted by Chris Heller @ 3:06 PM
22 comments
22Comments:
Hi Chris,
Great article. Our site is working to implement Shibboleth as our IDM and Single Signon solution for PeopleSoft. We use Apache to inject Shibboleth HTTP Headers and prxy requests to PeopleSoft. We are running into an issue where PeopleSoft seems to remove the HTTP Headers. Are you aware of this behavior? Is there a workaround to eliminate the header removal.
There's lots of, ummm, unusual behaviour with signon PeopleCode, but dropping headers is a new one to me. Our Desktop Single Signon stuff uses custom headers to communicate between the web server and app server without problem, and I know of lots of other people doing this as well.
How are you actually accessing the headers in PeopleCode? Do any of the headers sent by the browser actually show up?
Hi Chris,
Thank you so much for getting back to me on this. The flow is as follows:
User requests http://server:port/psp/instancename/EMPLOYEE/HRMS/h/?tab=DEFAULT
from an external link. Apache intercepts the request inserts the custom Shibboleth headers and redirects to the ps url (GET request). My signon PeopleCode fires and the headers are not present. I am then redirected to the login screen with a message stating "incorrect userid or password". If I simply request the url again my PeopleCode finds the headers and logs me into the correct page within PeopleSoft.
I wrote a test servlet that simply dumps the headers and installed it on the PIA server. When I access the test servlet it finds and prints the headers. I am therefore confident that the headers are being injected properly.
I am attempting to implement this on PeopleTools 8.48.03 (Oracle Application Server on Redhat Linux).
I have not configured guest signon within the WEB_PROFILE. Should I simply be able to submit a get request (with custom headers) to a page in PeopleSoft and read the headers within signon Pcode? Do I need to implement guest access to bypass the signon process?
I have written the following Pcode to simply access the header info:
&requestParams = %Request.GetParameterNames();
&requestHeaders = %Request.GetHeaderNames();
Upon first request to the url the request object does not contain my custom header information. I am interrogating the request object with the PeopleSoft debugger.
I appreciate any help you are willing to provide.
The problem is that you won't get signon PeopleCode to (reliably) run unless you have a public access account configured or it is a POST request with the signon page stuff.
So for your scenario you need to setup a public access account (it can be something with no access) and then sign the person on appropriately from the headers inside your signon peoplecode.
If you're planning on going to the Alliance conference, come find me and we can chat more about the other issues that you may encounter along the way.
Hi Chris,
Thanks again for your assistance. Unfortunately I will be unable to attend the Alliance Conference this year. I will setup a public access account and give it another try.
Will I simply need to read the headers and Authenticate the user? Once I setup public access are there many issues I will need to address?
Thanks Chris.
Hi Chris,
Thanks to your help I resolved my issue. I truly appreciate your help on this.
Thanks
Chris,
Thanks for this article. It really helped to solidify in my mind how we should approach SSO. Thanks!
Hi Chris,
Thanks for the excellent post. I'm fumbling my way through setting up IIS as a reverse proxy with the goal of using NTLM authentication for "desktop signon" and have gotten a little stuck. I'm not sure how to parse the header that IIS is adding to the request. I've tried using the &requestParams stuff that Goodie mentioned in a previous post, but it seems my debugger session doesn't really start catching code until the signon is complete. I'm trying to interrogate the header before that occurs -- in my custom signon PeopleCode.. Any ideas?
Chris,
I think I've figured out my problem from yesterday -- have been looking at the headers from another random PCode event post-signon. Sorry to have bothered you ... but would like to reserve the right to do so again should I get stuck :-)
Glenn
glenn.merberg@quadrint.com
looks like i hit right place..here is what i'm trying to solve.
-had IIS6 with siteminder agent on it
-iiS6 is proxying weblogic
now i want to bypass peoplesoft signin page.
Basically i can get userid information in the http headers, when i access siteminder protected url.
How can i implement this? we're having peoplesoft9. Any ASP code samples appreciated.
PeopleSoft is not built with ASP, so it does not use ASP code.
You'll want to check PeopleBooks for information about the Request object in PeopleCode.
but i can have asp code at the root of IIS server, which gets the remote user env.variable, where the the asp realm is protected by netegrity siteminder. Then i can post it peoplesoft login url with autosubmit. Any asp code please? we've PS9.
Also any security feature built around while passing remote_user? because anybody can send the request thru lwp agent etc., if he knows the user id who has entitlements.
Hi Chris,
We have setup the public access account and have PeopleCode working to read headers that are injected by Shibboleth. Everything works 95% of the time, but periodically we receive the error Invalid UserID and Password in our logs. How could this be? Could PeopleSoft be reading from cookies on the browser and trying to log the user in via PS single sign on? Any help would be greatly appreciated.
@Tomcat Tuning and Performance
There are a few different things that we've seen and had to add code to get around. One is that IE sometimes does some weird things with caching old sessions, so even though you think that you're logging someone in for a new session, the old session gets used. We just detect when this happens and force another login attempt (but we do it silently so the user does not realize that this has happened).
We're doing a session at OpenWorld on debugging these sorts of things. If you're there, be sure to come by and check it out.
@Amar, sorry for the delayed response. I didn't your extra comment until Tomcat's was posted.
Anyways, yes, you can send along the REMOTE_USER information in an HTTP header, but as you mention (and we pointed out in the original blog post) this is extremely insecure because there is no validation from the PeopleSoft side that it wasn't spoofed.
We've shown a few different people how easy it is to add extra HTTP headers in a request to PeopleSoft (or any web app for that matter), and they're generally surprised by just how easy it is.
So, you definitely can't just trust having an IIS proxy in front of Peoplesoft without doing some more work to ensure that someone can't just log themselves in as whoever they want.
Hi,
I'm trying to implement the SSO with JCIFS.
I'm trying to read the "Authorization" Header (that contains NTLM string)in the PeopleCode, but it only appears in the first HTTP GET of the request.
so from my signon peoplecode point of view, this parameter does not exists.
is there any way to make this parmeter more persistent ? or to read the Windows ID somewhere else ?
Regards
I was able to achieve the SSO to trust the thridparty authenticated cookie.. To achieve this as we know, we have to enable the public access and then the username/password should be given in the DEV Webprofile... But now the problem is when an AAF notification delivered URLS like http://host:port/psp/Opportunity.GBL goes for task.. I mean, when the user clicks the URL in the email it shows the You are not authorized instead of redirecting to Singon Page.. Is there any fix for this...
Hi Chris,
I would like to implement the single sign on into PeopleSoft application using the desktop windows login. COuld you please provide me a detaileds steps to implement it.It would be of great help to proceed with implementing it.
Thanks
Ravi
Hi Chris,
I log in to a website using an id and password. After logging in to the website, there is a link for Peoplesoft page. When I click on the link, It redirects to the peoplesoft page without asking the login credentials. What I would like to know is that how the credentials which I give in the website gets passed to our Peoplesoft and what kind of authentication methods are processed?
hi Chris,
Thanks for the blog, it helped. I am trying to implement desktop SSO for peoplesoft using Web Server level authentication. But I am not able to figure out how would you allow the support team to login with a different account like say psadmin account.
I believe we change the cmd=login to cmd=start in signon.html and need to replace this in all the html files used in the web profile.
Kindly help as I have reached a deadend...
Regards,
Samy
Samy, we added specific code to our Desktop Single Signon product to handle letting people manually log in. Your signon code needs to differentiate between manual requests or automatic requests (which will depend on what you are doing for the automatic requests).
I'm not sure why you are changing the signon.html page though.
Hello Chris,
I've riched peoplesoft homepage but when I want to enter any page or click on any button the user automatically signout.
When I look in psadmin I can see that all users are signin with Public user...
And actually, in webserv log, I found two 'delete cookies' lines for each time a users is autoatically signout.
Have you any ideas on this?
Thanks.
Hello Chris ,
We are using the Single sign on in our system.When ever a user is trying to login to the system, he is getting the mesaage that "Domain is not included in the list of domains". I just want to change the error message users are getting.
If you can guide me where can I do the changes.That will be really helpful.
Thanks and Regards
Amit
Post a Comment
<< Home