Skip to content

Configuring Applications for Password Management

Password management is further governed by the capabilities of the connector in use for each application. Passwords can be managed through IdentityIQ for any application using a read-write connector that has the PASSWORD feature enabled; this feature is enabled when the features String attribute on the application contain the word "PASSWORD." The application definition, including its featuresString attribute, for each application is viewable in the XML representation of the Application object accessible from the debug pages or from the IdentityIQ console.

<Application connector="sailpoint.connector.LDAPConnector" created="1334252935835" featuresString="AUTHENTICATE, PROVISIONING, ENABLE, PASSWORD, MANAGER_LOOKUP, SEARCH, ACCOUNT_ONLY_REQUEST" id="4028833636890f860136a7ac1a6c054f" modified="1335456303423" name="ADAM Direct" profileClass="" type="ADAM - Direct">

Note

Not all read-write connectors have the PASSWORD feature enabled. The Connector Registry entry for each connector includes all the valid features for that connector in its featuresString attribute. Specifying PASSWORD in the featuresString of an application to which the feature does not apply does not successfully enable password management for the application. To view the Connector Registry entries from the debug pages, select Configuration from the Objects list and click List. Then click ConnectorRegistry to view the connector registry XML.

Defining a Password Policy

Complete these steps to define an application's password policy:

  1. Open the application definition. From the navigation menu, go to Applications > Application Definition > select application from list or click Add New Application to create a new application.

  2. Open the Password Policy tab.

  3. Click Create New Policy to create a new password policy, click a policy name in the list to edit an existing policy, or click Add Existing Policy to select a predefined password policy from the dropdown list, see Policy Reuse (Link).

  4. Name the policy (required) and provide a brief description. Specify any required password characteristics. Most of these characteristics are self-explanatory.

    These few are further explained here since they might be unclear:

    • Password history length: specifies number of previous passwords in password history to check against for uniqueness (prevents re-use of a password over the specified number of password changes); the current password is included in the count

    • Validate passwords against the password dictionary: compares password to an internally-stored, implementation-specific password dictionary, ensuring that the password is not, and does not contain, any word in that dictionary (see Password Dictionary below)

    • Validate the password against the identities list of attributes: ensures that values stored as Identity attributes (for example, last name, department, office number, region) are not used as the password

    • Validate the password against the identity’s account attributes: prevents values stored on the application account from being used as the password

Note

The password history, if a Password history length value is specified, it is stored as a <PasswordHistory> element on the <Link> (account representation) within the Identity object. It is stored as a comma separated values list of encrypted passwords. The number of passwords stored is determined by the Password history length value specified. New passwords set for the account cannot match any password in the list.

Select an Identity Filter if this policy should only apply to certain sets of Identities. The default Identity filter is All, which means the policy applies to all Identities. Other options are:

  • Match List – specify Identity Attributes or Application Attributes/Permissions by which Identities can be matched for this policy to apply (for example, Identity Attribute: Department = Accounting)

  • Filter – specify a filter (as CompoundFilter XML) that can be used to identify Identities to which this policy applies

  • Script – specify a segment of beanshell that selects Identities that should use this policy

  • Rule – specify a rule (type: IdentitySelector) that returns a list of Identities to which this policy should apply

  • Population –apply this filter to the Identities in an existing IdentityIQ Population

Note

The first policy defined should be the default policy that applies to all users. This policy serves as the "fallback" policy if none of the more restrictive policy Identity Filters apply to the Identity whose password is being validated. If more than one policy is specified with Identity Filter = All, only the last one created is applied in any Identity password validation. This is further explained in the Password Validation Process section.

Password Dictionary

The password dictionary is a set of words (or character strings) that have been deemed impermissible as passwords or password contents for the specific IdentityIQ installation. It is populated by importing a Dictionary XML object through the iiq console or the Import from File option under System Setup. The XML looks like this, and the prohibited words in the password dictionary are included as <DictionaryTerm> elements:

``` <!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">

  <sailpoint>  
  <ImportAction name='merge'>  
        <Dictionary name="PasswordDictionary">  
        <Terms>  
        <DictionaryTerm value="password"/>  
        <DictionaryTerm value="identity"/>  
        </Terms>  
        </Dictionary>  
  </ImportAction>  
  </sailpoint>

`` Include the` element to add new terms to the dictionary without overwriting the existing dictionary entries. Omit this element to overwrite the dictionary with a new set of terms.

If removing terms or replacing the entire dictionary, then delete the dictionary object first using the console or debug pages. The terminator will handle removing both the Dictionary and the dictionaryTerms.

Note

Terms included in this dictionary are prohibited even as any part of a password when password dictionary validation is enforced. For example, if the term "rock" were included in the password dictionary, these passwords would all be prohibited: rocketlauncher, sprocket, Sh@mrock125. Additionally, validation against the password dictionary is case insensitive, so RocKeTTe would also be prohibited in this case.

Policy Reuse

Previously created policies (for example, ones created for one application but applicable to more than one application) can be added to an application instead of recreating the same policy over and over. For example, if superuser accounts on all applications have the same password requirements, the superuser policy could be created once and copied to all applications.

To copy an existing policy from one application to another:

  1. On the Password Policy tab for the target application, click Add Existing Policy.

  2. Select the desired password policy by name. The password policy characteristics are displayed for review.

  3. Configure the Identity Filter to apply the policy to the appropriate set of Identities for this application. Filters might differ from one application to another (for example, different application attributes or permissions or different Identities attributes can designate a superuser on one application but not on another), so they do not carry over between applications in this policy sharing feature.

  4. Click Save to save the filter on this application.

The policy now appears in the application's Password Policies list with a warning icon. Hovering over this icon displays the message "Be careful editing this policy, it is also used by another application." Changes made to the requirements in a shared policy affect all applications using that policy. Changes made to the Identity Filter on these shared policies only affect the individual application's use of the policy.

Password Validation Process

In many cases, the password policy for an application applies to all users, so there is only one password policy per application. Sometimes, more than one policy is created for a single application to specify different password requirements for different levels or types of user access. In the password management process, when a user's password is being changed, the policy checker scans all of the policies that apply to the identity and creates one super-policy that covers all of the restrictions for that user.

If no password policy is defined for the application, no password policy is enforced and any password entered for a password change is accepted by IdentityIQ and passed to the application to be set as the account's new password.