Wednesday, October 27, 2010

ITIM Spooky Password Behaviour

TIM and TAM experts will already be aware of how to provision TAM accounts from TIM and you will probably already be aware of how to provision GSO credentials from TAM to TIM. If so, this article may bore you but I did come across some rather odd behaviour that I wasn't really expecting.

In my provisioning policy for my TAM account, I was attempting to set my GSO credentials using Javascript and for some reason I decided to use the ersynchpassword attribute.

All was well when creating TAM accounts for existing PERSON objects in TIM. However, when I created a new PERSON object, I was presented with a failure in the provisioning of my TAM account:

CTGIMA617E The account {account} cannot be created either because the account is disallowed for the user or one or more attributes are not compliant with provisioning policy.
Odd. Because when I manually requested the account to be created... it appeared without fuss.

My suspicions were that the ersynchpassword was not "available" at provisioning time so I dropped the following code into the provisioning policy:

Enrole.log("SSO", "uid is " + subject.getProperty("uid")[0]);
Enrole.log("SSO", "ersynchpassword is " + subject.getProperty("ersynchpassword"));
Enrole.log("SSO", "personpassword is " + subject.getAndDecryptPersonPassword());


The result wasn't terribly surprising in that ersynchpassword was null or empty. At least, that's what it seemed like at first glance when I noticed the following log messages:

Error: uid is account01
Error: ersynchpassword is
Error: personpassword is passw0rd


The real surprise, however, came when I read on through the log. Within milliseconds of the above messages, the following messages were presented:

Error: uid is account01
Error: ersynchpassword is passw0rd
Error: personpassword is passw0rd

CTGIMA617E The account account01 cannot be created either because the account is disallowed for the user or one or more attributes are not compliant with provisioning policy.

So what do I make of this?

Well, it's best to use the getAndDecryptPersonPassword() method within this particular provisioning policy, that's for sure. But ONLY on account creation. Password changes need to be evaluated using the ersynchpassword. Luckily, there is a catch-all:

if (subject.getProperty("ersynchpassword")[0] == null) {
    return "sapGSO (Web Resource)"
        + "|" + subject.getProperty("uid")[0]
        + "|{clear}" + subject.getAndDecryptPersonPassword();
} else {
    return "sapGSO (Web Resource)"
        + "|" + subject.getProperty("uid")[0]
        + "|{clear}" + subject.getProperty("ersynchpassword")[0];
}


There are still some questions left unanswered here, though. Why was the policy evaluated TWICE and why did the first failure drive the CTGIMA617E message (rather than the second successful evaluation). Maybe someone in the land of the development team can explain it. And also explain why the ersynchpassword didn't manage to appear until the second evaluation just a 100 milliseconds after the first evaluation.

Then again... maybe it's because it is almost Halloween and it's the time of year for strangeness!

NOTES:
The above scenario was produced using ITIM v5.1 (Fix Pack 1) running on WebSphere 6.1 on a Windows 2003 Server. I'm quite sure I've used ersynchpassword in the past on ITIM v5.0 instances and did not see this behaviour!
Post a Comment