This topic has 5 replies, 3 voices, and was last updated 5 years, 8 months ago by Jake Feasel.

  • Author
    Posts
  • #15404

    Hi all,

    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.

    Yours,
    Patrick.

    #15406
     ssripathy
    Participant

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

    #15407

    There is no such mapping from HR to OpenIDM. The password is generated onCreate and later changed by REST.

    #15448
     Jake Feasel
    Moderator

    Perhaps your mapping from HR to OpenIDM could include an onUpdate script which generates a new password which conforms with the new policy?

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

    #15629
     Jake Feasel
    Moderator

    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.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?