Previous Topic: Using FailoverNext Topic: PLS Support for FIPS and IPv6


Enable Application Password Propagation

Currently, in an SSO endpoint, every SSO user record contains a login application and every login application record contains a username and password. This username and password does not have to be the same as the SSO username. For example:

SSOuser1 Username=Doe Password=Doe
	TelnetAppl1 Username=Doe1 Password=Doe1  (Unix Host Srv1)
	TelnetAppl2 Username=Doe2 Password=Doe2 (Unix Host Srv2

SSO has password synchronization. If you (or SSO) change the password from TelnetApp1, SSO also changes the password for TelnetApp2.

If you put CA IdentityMinder into this equation, Admin is able to do password synchronization and has an SSO Connector and a UNIX Connector. You now have the following scenario:

Global User=Doe
SSO User=Doe
	Inside SSO TelnetApp1 username=Doe, TelnetApp2 username=Doe
Unix User on Srv1=Doe
Unix User on Srv2=Doe

If you change the password for the global user Doe and propagate the password to all of the global user accounts, the password will change on the following Endpoint Types: SSO, Unix Srv1 and Unix Srv2. However, the password in the loginapplications (TelnetApp1, TelnetApp2, and so forth) for the SSO user will not be changed and those using SSO cannot use SSO to log into their applications anymore because the password stored in their loginappl record is out of sync.

To solve this problem, a master application, for example, eTrustIAM, can be defined and TelnetApp1 and TelnetApp2 can be set to use eTrustIAM as the master application. The PLS Connector can then update the password of the master application eTrustIAM when it receives the password propagation request caused by the CA IdentityMinder global user password change. As a result, the Policy Server updates the passwords for TelnetApp1 and TelnetApp2. Because the UNIX Connector updates the passwords for the user in both Unix Srv1 and Unix Srv2, and the PLS Connector updates the SSO password if the user uses the SSO authentication method, the passwords in all levels are in sync.

If you are using an older Policy Server version that does not have the eTrustIAM master application defined automatically after installation, do the following to use this feature:

If you want to integrate admin applications (Provisioning Manager, IA Manager, and Self Service) with SSO, do the following to start these Admin applications through the SSO client:

  1. Using Policy Manager, create SSO applications for each Admin application (Provisioning Manager, IA Manager, and so forth).
  2. Set eTrustIAM as the master application for these SSO applications.
  3. Create TCL scripts for each Admin application, (These are used to start the applications through SSO.), and put these TCL scripts in the following directory:
    eTrust Policy Server\Scripts