(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).
Labels: Products, Security