PeopleTools 8.51 SSO using Oracle Access Manager 11g (11.1.1.3)

For many years, OAM has provided a well documented 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:

1. 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.



2. 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.



3. 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!

My Environment:
- Apache 2.2 on Solaris, as reverse proxy for a PeopleTools 8.51 PIA instance
- Webgate 10.1.4.3 for Apache
- OAM 11.1.1.3

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.

Update 06-Jan-2012:
I have been asked if any official PS-OAM integration docs or white-papers exist. Sorry, I have not found any silver bullet document yet. What I use is a combination of the following docs:
- PeopleTools 8.51 Security Admin
- Oracle Access Manager 11g Policy Management

Unable to open wallet error while bringing up OVD11g

OVD 11g installed on Windows 2008 workstation fails to start with the error below in diagnostic log

Error:

PKI-02002: Unable to open the wallet. Check password

Reason:

There is a variable-id called "TEMP" in opmn.xml that holds the location where a couple .tmp files are created when OVD wallet file cwallet.sso is accessed.

Our opmn.xml has the following value for TEMP :

C:\Users\ADMINI~1\AppData\Local\Temp\1

Somehow the directory "1" was missing on our server. Since there was no directory to create the files, OVD refused to start.

Solution:

Creating an empty folder called 1 and attempting to start OVD created the required .tmp files and folders needed to store the wallet information

Good ol' Oblix schema alive and well in OAM11g

While preparing to install OAM 11g, some of us were curious whether all the "ob..." attributes would remain intact or if they would be renamed with, for instance, an "orcl..." prefix. It struck one of my colleagues that the "ob" attributes would survive, if only to facilitate a workable upgrade path or to ease product development.

Whatever the case, it turns out that the attributes we've all known since the days of NetPoint and COREid have endured and can be found in OAM 11g after all.

During the LDAP pre-configuration step - one of the many, many steps required to get OAM installed - an LDAPConfigPreSetup.sh script is run, which performs the following:

• Creates the Roles and Reservation User containers in OID, if they do not already exist.
• Loads Identity product specific schema into the Directory

The LDIFs used to load the schema into OID contain all the old Oblix attribute names, and in my environment they are found in [MW_HOME]/Oracle_IDM[x]/oam/server/oim-intg/schema.

• OID_oblix_pwd_schema_add.ldif
• OID_oim_pwd_schema_add.ldif
• OID_oblix_schema_add.ldif
• OID_oblix_schema_index_add.ldif

This is great, because it should mean that we can count on using familiar attributes like obuseraccountcontrol and obusersessiontimeout.

Some things just don't change...at least not for another 6 months or so...

EM Console 11g shows OID is down

The Enterprise Manager Fusion Middleware Control 11g shows OID is down even though opmnctl shows OID is up.

The EM console also displays the following error while trying to access the OID instance under Farm_IDMDomain -> Identity and Access -> oid1 or while trying to create a wallet for SSL

Error:

Information Configuration settings are unavailable because /Farm_IDMDomain/OID_Inst/oid1 is down.

There could be 2 reasons for this.

Reason1:

The WebLogic user password used by EM Console to monitor OID is not correct.

Solution:

• Go to the Farm drop down menu on the top of EM Console -> Agent Monitored Targets -> Configure . Verify if the Weblogic Monitoring User Name is correct and Change the WebLogic Monitoring Password to the correct password. Click Ok.
• Check the OID status now.

Reason2:

The IP address/hostname given in the Middleware Administration Server Service URL is wrong.

The following is an example of the Middleware Administration Server Service URL

service:jmx:t3://your_ip_address:7002/jndi/weblogic.management.mbeanservers.domainruntime

Solution:

• Go to the Farm drop down menu on the top of EM Console -> Agent Monitored Targets -> Configure .
• Try using hostname instead of IP address. Click OK and verify the status of OID from EM console.