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