Client/Server Single Signon for PeopleSoft

By Larry Grey • March 26, 2008

Larry recently mentioned that we had finally recorded a Flash demo for the client/server portion of our Desktop Single Signon for PeopleSoft product. In a nutshell, what it does is let your developers and reporting power users (Query, nVision) access PeopleSoft without getting prompted for their login. Instead, their Windows/Active Directory credentials that they used to login to the network are used to establish their session.

One interesting aspect of implementing our Desktop Single Signon with the client/server support is that you can now run a PeopleSoft system without anyone(3) having a password inside PeopleSoft. You’d still have the accounts needed for booting the appservers, process schedulers, etc., but no passwords that a human (1) would ever use would need to be stored inside PeopleSoft. Even developers or people promoting changes from one PeopleSoft instance to another (such as from test to production) would not have passwords within PeopleSoft.

What’s really cool about this is that it leverages something that has existed since PeopleTools 1, which is the psuser.dll user exits. PeopleSoft delivers psuser.dll without any delivered functionality in it, except for a couple of C functions that PeopleTools will call at login time. The delivered psuser.dll does nothing, but PeopleBooks documents how you can supply your own implementation to override signon logic for 2 tier and 3 tier connections.

Back in the client/server heyday this functionality was used by a few different vendors for doing client/server single signon. The only one that I could find from a few web searches was Novell’s Single Signon for PeopleSoft, but they appear to have given up on that as of PeopleSoft 7.x. In fact, they don’t even list PeopleSoft at all in their list of applications that they support (2). So, Grey Sparling is the only vendor selling a client/server single signon product for PeopleSoft 8 applications today. We’re first and last to market!

All kidding aside, it is interesting that no one does anything with the client/server aspects of PeopleSoft, since you quite literally can not run a PeopleSoft shop without at least some people using the client/server tools.

When your developers make a change to PeopleSoft, it is typically done through a 2 tier Application Designer session. Same thing for promoting changes between different environments. Same thing for applying maintenance. There are also still a number of places that use the client/server reporting tools. I know of a few places where the 3 tier Query users number in the hundreds (including one customer with somewhere north of 800 Query users).

And there are no password controls for 2 tier connections. If someone’s password has expired and they try to login via 2 tier, guess what happens? They’ll get logged right in. Why? Because there is no signon PeopleCode for 2 tier connections and password controls are enforced with signon PeopleCode.

Another interesting wrinkle with giving 2 tier access is that you may be inadvertently circumventing other security measures that you have in place for PeopleSoft web access. How?

Suppose that you use the delivered PeopleSoft support for validating your user logins against an LDAP directory. Your users type in their username and password in the standard PeopleSoft signon screen in their web browser and the PeopleSoft application server tries validating those against the LDAP server, where there are more stringent security measures in place than PeopleSoft supports.

Except that PeopleTools will always try the username/password against the PeopleSoft database first, checking in the PSOPRDEFN table. You can’t disable this behavior (which is documented in PeopleBooks). Your 2 tier users can login to a PeopleSoft web session by just using the same user/password that they use for 2 tier. The LDAP server will never be consulted and neither will any PeopleSoft password controls.

Most PeopleSoft shops deal with this by having anyone that has 2 tier access use a different user account for client/server sessions vs web sessions. That is better than bypassing security controls, but most auditors are not too happy about people having multiple accounts for the same system.

So if your PeopleSoft auditors haven’t hit you up on this issue, it’s probably because they don’t realize that it is an issue.

One interesting technical implementation detail is that although we plug in to the client/server tools through the delivered PeopleSoft user exit, we actually utilize the web single signon to establish the client/server session (including mapping from your Windows user name to your PeopleSoft user account name.

This means that we could potentially port the client/server single signon part of Desktop Single Signon to work with other web single signon products that support PeopleSoft (e.g. Oracle, Sun, IBM/Tivoli, home grown, etc.). No promises, but let us know your thoughts if you’re interested.

(1) You would still have the database level accounts that are independent of the application being used (i.e. SYSADM or sa). I wasn’t implying that DBAs aren’t human though. Some of my friends are DBAs 🙂

(2) Novell does still list SAP’s Windows client’s (SAP R/3 front.exe and saplogin.exe) in their list of supported Windows applications.

(3) See the comments. Brent Martin thought of a use case that I had forgotten about (but shouldn’t have!).

Labels: 2008, Security

Stay Updated

5 Replies to “Client/Server Single Signon for PeopleSoft”

  1. Hey there, Chris, Jim and Brent: the only PS blogs worth reading.

    So, this is where my shop stands: Oracle Access Manager / Webgate for standard PIA authentication; LDAP authentication for Journal Spreadsheet Upload (as Chris said, it doesn’t support redirects or a way to display the credential prompt even if it did, so OAM/Webgate won’t work).

    After giving up the fight to get the nVision drill down add in (DrillToPIA.xla) to work correctly in our very heterogenous environment (group policy differences; IE version differences; Excel version differences) and the inherent limitations of the DrillToPIA (painfully slow performance going through RENServer versus instant response via fat client; inability to do pass-through autentication when launching from Firefox; etc.) we have decided to deploy fat nVision through terminal services.

    So we’ll be doing what I thought we would never have to in this day and age: build our own psuser.dll. We can’t really give our native PS credentials (passwords) and they are not managed (we don’t have complexity / expiration rules, and I don’t know whether the fat front end even honors them anyway).

    Oh well, off to work we go.

  2. Good catch Brent.

    The ExcelToCI and Journal Upload both login by generating HTTP requests (not using the client/server connection), but they are hard-coded to always prompt for a username and password.

    This hard-coding is actually why we have specific exception code in the Desktop Single Signon code to not do the standard SSO challenge for these (because the PeopleTools code inside these spreadsheets is not prepared to handle any redirects).

    So, it looks like I was slightly too aggressive in claiming zero. I’ll edit the post until we can figure out a way of dealing with that 🙂

  3. That’s a very nice new feature. This is something my current client is interested in because they’ve deployed the windows Query Manager to a bunch of desktops and now they have to maintain passwords in PS for some users but not all.

    I noticed you say “no passwords that a human would ever use would need to be stored inside PeopleSoft.”

    Does that mean that in addition to the Windows-client programs, import tools like ExcelToCI and Journal Upload no longer require PeopleSoft passwords? I was thinking that was a fairly difficult problem to work around.

Comments are closed.

Request a Demo