When Identity Manager and SiteMinder are integrated, 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 12.x and SiteMinder 12.x
When you are integrated 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.
If you make changes from Identity Manager, we mirror those changes on the the SM server and policy store by issuing a SMIMSCommand via the 4x tunnel.
DO NOT modify the SM policies in SM Admin UI, 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
Release: CAIDMB99000-12.6.7-Identity Manager-B to B