You would, of course, be wrong. At least, if you want to make use of GSO credentials, you would be wrong. Maybe. Possibly.
You see, the provisioning of GSO credentials just doesn't seem to be that easy!
This article assumes the following:
- the reader has a basic understanding of IBM Tivoli Identity Manager
- the reader has a basic understanding of IBM Tivoli Access Manager
- the reader understands GSO credentials within TAM
- the version of ITIM being used is v5.0 (or higher)
- the version of TAM being used is v6.0 (or higher)
- the TAM Combo Adapter is being used (v5.0.9)
For an explanation of the problem, let us assume that a resource has been created within the TAM domain called backed. In pdadmin, we can create this resource as such:
rsrc create backend
In ITIM, we have a provisioning policy created with all the standard default TAM attributes being populated (such as cn, sn, our TAM groups, etc.). We check the box for Single Sign On Capability which leaves us with the Resource Credentials to populate.
In our environment, we have password synchronisation enabled across all systems and the GSO credentials will be no different. In other words, should a user change their password in ITIM, their TAM password and their GSO resource credential passwords will also be updated.
The "Constant Value" option for the Resource Credentials on our Provisioning Policy form is of no help for a User ID and Password that will be different for each user:
Which leaves us with the option of scripting the credentials. The documentation provided with the TAM Combo Adapter at least tells us that the TAM Resource Credentials must be provided in the following format:
RESOURCE NAME|USER ID|PASSWORD
In our case, that means that our javascript will look something like this:
"backend (Web Resource)" + "|" + parameters.eruid[0] + "|" + {something}
We have a problem. We've always known that we can use parameters.eruid[0] for our User ID but what do we use for our password? A little bit of crawling around the documentation tells us that when password synchronisation is enabled, the ersynchpassword can be used to retrieve the password. So our {something} becomes ersynchpassword, right?
Wrong!
In fact, when we do this and provision an account (with a password of auiTNG85) our secAuthData attribute in LDAP contains the following:
secAuthnData:: IUAja0BAQEBAQEDJKioqKioqKqgh5CMjIyMjIyMjIyMjgiMjIyMjIyMjIyMjniMjIyMjIyMjIyMjNyQk
How do I know that this is wrong? I know because I manually created the Resource Credential via the pdadmin command prompt and know that the result I'm looking for is:
secAuthnData:: IUAjZyoqKioqKip6JiYmJiYmJiYmJiZpIVQhT0BAQEBAQEBIQEBAQEBAQDghOSUlJSUlJSUlJSUlJSUA
Indeed, if I hardcode my Provisioning Policy to set {something} to my password (auiTNG85), I get the same incorrect result. Odd? Not really. If you dig further into the documentation you will see that there is some funny business going on with the TAM Combo Adapter and the password in the Resource Credential attribute on the Provisioning Policy MUST be prefixed with {clear}. In our hardcoded entitlement, we would therefore have:
"backend (Web Resource)" + "|" + parameters.eruid[0] + "|" + "{clear}auiTNG85"
Now, when we create our account, the secAuthnData is set correctly! Of course, I'm hardcoding the password still so I need to do something about that! We need to re-introduce our ersynchpassword attribute but ensure we are prefixing is with {clear}. And the reason we do that is because ITIM is just too clever by half and has already Base64 Decoded the attribute on our behalf!
The resulting secAuthnData is now set to:
secAuthnData:: IUAjZyoqKioqKip6JiYmJiYmJiYmJiZpIVQhT0BAQEBAQEBIQEBAQEBAQDghOSUlJSUlJSUlJSUlJSUA
Perfection. I'm sure the documentation contains all the information required to get this result but it isn't instantly clear that this is how you should be going about the GSO Credential Password Synchronisation problem.
No comments:
Post a Comment