Integrating Identity Manager with SiteMinder, there is some confusion as to how Password Policies work.
How do Password Policies work, when Identity Manager and SiteMinder work together?
All versions of IdentityManager 14.x and SiteMinder 12.x
When integrating IM/SM both IM and SM have their own copies of each password policy: IM in the IM Object Store and SM in the Policy Store.
When making changes from Identity Manager, those changes need to be mirrored on the SM server and Policy Store by issuing a SMIMSCommand via the 4x tunnel.
DO NOT modify the SM policies in SM AdminUI, as they will not get modified in IM and we’ll end up out of sync. SiteMinder has no mechanism to synchronize data back to IM at all.
In an IM/SM integrated environment, both IM and SM are involved in the process.
It works like this:
Both IM directory and SM directory have the same %enabled_state% flag. Upon logging into SiteMinder Web Agent, the Policy Server will check that value to see if everything is valid, or if the user has to take some password action (e.g. Password Must Change, or password expired, etc). Based on this flag, SiteMinder will redirect to the URL that is specified in the password policy. Typically, this is Identity Manager’s password services task.
When integrated with SiteMinder, Identity Manager relies on SiteMinder to authenticate and send an SMTOKEN value in the redirection header. Identity Manager takes that SMTOKEN value and asks the Policy Server that is it integrated to see if this is a valid authenticated session and who the user is, so we can determine the user object to reset the password of.
Then on the IM password services page, the password policy is checked again to make sure the customer doesn’t violate any password composition or reuse rules. If everything is ok with the password, IM resets it and redirects the user to the original page that the customer was trying to access.