PeopleTools 8.51 SSO using Oracle Access Manager 11g (188.8.131.52)
For many years, Oracle has provided a well documented OAM SSO solution for PeopleSoft using typical header variable integration. However, PeopleBooks for PeopleTools 8.51 has become so, shall we say, refined, it’s now harder to acheive success with such time-tested integration steps.
My hard-fought, but successful integration attempt rested on 3 key things:
- Turning on Allow Public Access in the PeopleSoft PIA Web Profile – still required.
I realize this was done in previous Tools versions, but I don’t find it as clearly documented by Oracle for Tools 8.51. The Web Profile screen shot is gone and they no longer refer to the checkbox “Allow Public Access”; they simply say you have to set up the “public access user ID”. So you have to make a small inference as to what to configure.
- Using “cmd=start”, and not cmd=login. E.G. http://myhost:8080/psp/mypsoftdb/?cmd=start.
cmd=login just gave me the PeoplSoft login page after authenticating through OAM, rather than the user’s home page in PeopleSoft. Again, this was documented more clearly in the past, but not for the latest Tools versions. An experienced colleague, as well as an OAM 10g/PeopleTools 8.50 example from Metalink, pointed me to using cmd=start.
- Lowercasing header variable names when using Signon PeopleCode to retrieve them from the session. E.G. &userID = %Request.GetHeader(“ps_sso_uid”);
This was the most important nuance. Although PeopleSoft conveniently provides Signon PeopleCode for this integration out-of-the-box, it does not hint that the header variable name containing the OPRID might need to be lowercased.
The header var “PS_SSO_UID” is delivered in Signon PeopleCode, as the variable that PeopleSoft expects OAM to provide. I could dump the headers from the request object to prove that Signon PeopleCode could indeed see that header variable, but somehow it still could not read the value it contained. A colleague mentioned that another one of our customers integrated a home-grown app with OAM and had the same problem…until they tried lowercasing the header! Replacing “PS_SSO_UID” with “ps_sso_uid” did the trick. OAM 11g-PeopleTools 8.51 SSO — done!
– Apache 2.2 on Solaris, as reverse proxy for a PeopleTools 8.51 PIA instance
– Webgate 10.1.4.3 for Apache
– OAM 184.108.40.206
It could be that you don’t need to lowercase your PS_SSO_UID header var name in your environment. Or maybe this will change in future patches of OAM 11g. But, if you figure you did everything else correctly, then give this a try! I hope it helps.