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|
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’
– of truly being ‘Second to None’.
Labels: #YYCRecovers, Nulli
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 firstname.lastname@example.org.
Many thanks to Ludo Poitou for the encouragement and congratulations to Rob who made it all happen.
Labels: ForgeRock, OpenAM, OpenDJ, OpenIDM
Monday, August 15, 2011
PeopleTools 8.51 SSO using Oracle Access Manager 11g (18.104.22.168)
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:
- 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 22.214.171.124
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.
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
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:
- 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
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
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 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
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...
replace the tags with the appropriate value for your environment based on the LDIF you extracted.
Labels: Bug, OAM, Upgrade
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 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