Monday, July 29, 2013


Nulli Gives Back to the Community – Floods Can’t Dampen Our Spirit!

On June 21, 2013, Southern Alberta was hit with devastating floods – the impacts both financially and emotionally will be felt for years.  Despite being a relatively small team, the flooding has impacted all of us at Nulli.  Some of our colleagues were temporarily evacuated from their homes, seeking shelter with colleagues, friends or neighbours until the dangers had passed.  Others had to stay evacuated until waters subsided, power was restored and cleaning out of contaminated belongings could be completed.  Yet others have family and friends who have had their homes and possessions completely destroyed and live day-to-day while they wait on flood policy and recovery decisions to determine their next steps for getting themselves into a home.

Flooded Neighbourhood - Sunnyside

The magnitude of the destruction is overwhelming and it is hard to comprehend the amount of resources that will be required to rebuild.  For many, the decision to rebuild or move out of flood prone areas will be uncertain for weeks to come as government guidelines and other factors come to fruition.

During these challenging times, Nulli has encouraged employees to give of their time wherever they can and to take time away from work to do so.  Our team has definitely been helping out in a multitude of ways.  Bringing their sweat labour, shovels, pumps, generators, fans, pressure washers, wrecking bars and bottomless energy, the Nulli team has placed their hearts on the line for anyone in need of a hand.  Everyone wants to help and everyone wants to make a difference.  When speaking of the volunteer support being offered by the Nulli team, a colleague recently stated, “I’m proud to be a part of Nulli, we have demonstrated our commitment to each other and to the community that we share so well”.
Nulli Team in High River

This has been a significant learning experience for all of us whether we have been impacted directly or indirectly; some of us have learned how to help while others have learned how to accept help.  The experience has been enormously rewarding on both a personal and community scale.  It’s been humbling to witness the wonderful things that people are capable of when faced with adversity and to support them in the process.

Nulli honours its’ commitment to community, its' values and lives up to its’ namesake 
– of truly being ‘Second to None’.

Labels: ,

Friday, June 14, 2013


Nulli - Keeping IAM Simple Stupid - ForgeRock Open Identity Summit

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  

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

Labels: , , ,

Monday, August 15, 2011


PeopleTools 8.51 SSO using Oracle Access Manager 11g (

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 for Apache

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


Friday, July 29, 2011


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

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

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 :

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

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

Friday, May 27, 2011


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 script is run, which performs the following:
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.
This is great, because it should mean that we can count on using familiar attributes like obuseraccountcontrol and obusersessiontimeout.

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

Labels: , ,

Friday, May 20, 2011


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

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

There could be 2 reasons for this.

The WebLogic user password used by EM Console to monitor OID is not correct.
  • 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.
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
  • 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.

Tuesday, December 21, 2010


Resources Missing After Upgrade

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

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

Labels: , ,

Thursday, November 25, 2010


Simple Mode Root CA Strikes Again

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 upgrade drops the old (now expired) root CA over the updated ones.

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

Labels: , ,

This page is powered by Blogger. Isn't yours?