How do Password Policies work when Identity Manager and SiteMinder are integrated?

book

Article ID: 37638

calendar_today

Updated On:

Products

CA Identity Manager CA Identity Governance CA Identity Portal CA Risk Analytics CA Secure Cloud SaaS - Arcot A-OK (WebFort) CA Secure Cloud SaaS - Advanced Authentication CA Secure Cloud SaaS - Identity Management CA Secure Cloud SaaS - Single Sign On

Issue/Introduction

 

When we integrate Identity Manager and SiteMinder, there is some
confusion as to how Password Policies work.

We'd like to know how do Password Policies work, when Identity Manager
and SiteMinder work together ?

 

Environment

 

All versions of IdentityManager 12.x and SiteMinder 12.x

 

Resolution

 

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.