Flooded Neighbourhood - Sunnyside

Nulli Team in High River

Labels: #YYCRecovers, Nulli

Nulli showcased our views on IM KISS - "Keep IAM Simple Stupid" demo at the ForgeRock Open Identity Summit.   Presenting identity management in a visible and open format with nothing to hide is a key principle of the open community that Nulli and ForgeRock support.   The demo highlighted a rapidly deployed suite of the ForgeRock Open Identity Stack running on 4 Raspberry Pi computers.   So for a few hundreds of dollars Nulli was able to demonstrate the use of OATH2 credentials from Google, Amazon and Facebook for accessing protected apps, provision accounts using the OpenIDM workflow engine and providing directory failover using OpenDJ.   All of this neatly packaged in a picture frame illustrating the process flow and server interaction.

ForgeRock Open Identity Stack running on Raspberry Pi

Truly lightweight, elegant and effective.   Want to learn more about our POC showcased in the IAM world?   Give me a shout at dsmall@nulli.com.  

Many thanks to Ludo Poitou for the encouragement and congratulations to Rob who made it all happen.

Labels: ForgeRock, OpenAM, OpenDJ, OpenIDM

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