January 18, 2017 at 2:12 pm #15404
I’ve been running openidm 3.1 with an old password-policy that I’m supposed to update. The new one is stricter than before, so some old passwords would no longer be allowed with the new policy.
Changing the policy basically works and is enforced when users change their passwords.
However, when there is an update from hr to managed/user, like the user changing the department, the change is rejected by openidm, due to a password-policy-violation. So currently I can’t enforce stricter passwords, since not getting hr-changes into openidm is a definite no-go.
Basically, I need to enforce the policy whenever a password is changed, not whenever some other attribute of an user is updated.
Any ideas? Can’t be the first one to stumple upon this issue, can I?
Any help would be greatly appreciated.
Patrick.January 18, 2017 at 2:59 pm #15406ssripathyParticipant
Have your tried removing the sync mapping of the password field from HR to OpenIDM and do an onCreate() event with a temp password (that matches the policy) for the user. I am guessing password changes don’t originate from an HR system anyway.
There is another way, but this would be simpler. HTHJanuary 18, 2017 at 3:08 pm #15407
There is no such mapping from HR to OpenIDM. The password is generated onCreate and later changed by REST.January 19, 2017 at 7:30 pm #15448Jake FeaselModerator
Perhaps your mapping from HR to OpenIDM could include an onUpdate script which generates a new password which conforms with the new policy?January 30, 2017 at 6:22 pm #15603
Sorry for the late reply, wasn’t in the office till now.
I simply can’t afford to lock out all users from all our services. For now it is fine if the users have a password following the old policy, but when they change it, they have to follow the new policy.
Basically, the mapping from HR to OpenIDM is completely unrelated to the password. I’m really surprised OpenIDM even bothers to decrypt the unchanged password and check the policy, when there is absolutely no change related to the password.
Imagine situations like “HR tells OpenIDM to lock the account RIGHT NOW and OpenIDM refuses to lock the account because the password has an policy issue”.
So I guess I need to create a custom password-change-endpoint enforcing the updated policy, disallow password-changes in OpenIDM and force users to perform password-changes via a custom-website. When all users have updated their password in compliance with the new policy, I can update the policy in OpenIDM. Something like that, anyway.
Or I switch to hashed passwords instead. Should avoid this issue as well.January 31, 2017 at 7:19 pm #15629Jake FeaselModerator
You could define a new password field, which has the stronger policies specified. Then within an onUpdate script you could check to see if the original password field has changed; if so, update the new password field with the new value. The policy for the new password field would then execute, and if the updated value does not pass the policy then the change will fail.
You must be logged in to reply to this topic.