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

Labels: PeopleTools 8.51 SSO OAM 11g header variable integration

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

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

Labels: OAM 11g, Oblix schema, obuseraccountcontrol

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

It is unlikely that many will have this problem, but if you do this could save some time and headache troubleshooting...

When you upgrade from 7.x to 10.1.4.0.1 the resources on policy domains and policies go missing. It appears that the only known fix for this is to manually recreate this data using the UI after the upgrade.

The other approach would be to proactively take them out of the directory server before you do the upgrade and then simply add them back afterward.

The resources themselves are still there after the upgrade. All that is really missing is the pointer from the resource action object to the resource.

These can be found by performing an ldapsearch with the following criteria:

search base: obapp=PSC,OU=oblix root,DC=,DC=com
filter: (&(objectClass=oblixWRSCAction)(obResourceID=*))
attributes: obResourceID

This will return all of the objects that have this value set.

After the upgrade run the same search and compare the results. Those values should be missing. If so, prepare an LDIF file to update the entries.

An LDIF entry to fix the missing obResourceID could take this form...

dn: obname=,obname=,obapp=PSC,OU=oblix,DC=,DC=
changetype: modify
replace: obResourceID
obResourceID:

replace the tags with the appropriate value for your environment based on the LDIF you extracted.

Labels: Bug, OAM, Upgrade

We discussed the expiration of this cert already in this post. I never thought i would see this problem again. Ahhh, was i wrong. When upgrading from COREid 7 to OAM 10, the 10.1.4.0.1 upgrade drops the old (now expired) root CA over the updated ones.

If you keep the faith and keep going the 10.1.4.3 patch set replaces it with the new one that is good until 2024.

Labels: OAM, Root CA, Simple Mode

I just had the most frustrating experience. I am in the midst of upgrading OAM 7.x to 10.1.4.3. I had all the components upgraded to 10.1.4.0.1 so I got backups taken. Afterwards one of the webpass instances did not work. Upon further inspection transfilter.dll was actually removed form the file system. Strange, but no problem, i grabbed a copy from another 10.1.4.0.1 webpass.

The transfilter.dll still didn't get loaded by IIS and it still did not work. I ended up trying numerour different things. I added and re-added transfilter.dll to the Default Web Site multiple times. I uninstalled 10.1.4.0.1 and re-upgrade; still go the same behaviour. I uninstalled webpass alltogether (purged registry, etc) and installed 10.1.4.0.1 instead of upgrading an old one; still got the same behaviour.

I had given up home when i decided to try adding transfilter.dll at "Web Sites" instead of "Default Web Site". Low and behold it took and loaded. Then I tried moving it back to "Default Web Site" and it worked there too. I was back! Frustrated, but back.

I have no idea what caused transfilter.dll to disappear in the first place. I have no idea why it would not load in IIS after it was replaced. I have no idea why moving it in IIS fixed the problem. I am thankful though and if this strange occurence ever recurs I will have a strategy.

Labels: IIS, transfilter.dll, WebPass

What's old is new again. Remember SAML Service in CoreID 5x? Sounds like OIF will be merged back into OAM in a future release.