test

Sun OpenSSO Enterprise 8.0 Administration Guide

Customizing Authentication

The following sections contain information on several features of the Authentication Service and the procedures used to enable them.

Enabling Account Lockout

The Authentication Service provides a feature where a user will be locked out from authenticating after a defined number of log in attempts has failed. By default, account lockout is disabled. When enabled, email notifications are sent to administrators regarding any account lockouts as well as recorded by the Logging Service. Only authentication modules that throw an Invalid Password Exception can leverage the Account Locking feature. These include Active Directory, Data Store, HTTP Basic, JDBC, LDAP, RADIUS, SafeWord, SecurID, and Unix. OpenSSO Enterprise supports two types of account lockout.

Physical Lockout

This is the default lockout behavior, initiated by changing the status of a specified LDAP attribute in the user’s profile to inactive. (The specified LDAP attribute is defined as the value of the Lockout Attribute Name attribute in the Core authentication module.) When physical account lockout is enabled an attribute in the user data store is used to hold information regarding the authentication attempts. This information includes:

  • Invalid attempts count

  • Last failed time

  • Lockout time

  • Lockout duration

Note –

An aliased user is one that is mapped to an existing LDAP user profile through configuration of the User Alias List Attribute in the user profile. If an aliased user is locked out, the actual LDAP profile to which the user is aliased will be locked. This pertains only to physical lockout with authentication modules other than LDAP and Membership.

Memory Lockout

Memory lockout is enabled by changing the value of the Login Failure Lockout Duration attribute (which defines how long a user must wait after a lockout before attempting to authenticate again) to a value greater then 0. The user's account is then locked in memory for the number of minutes specified. The account is unlocked after the time period has passed. There are special considerations when using the memory locking feature.

  • If OpenSSO Enterprise is restarted, all accounts locked in memory are unlocked.

  • If a user’s account is locked in memory and the administrator resets the account lockout mechanism to physical lockout (by changing the value of the Login Failure Lockout Duration to 0), the user’s account will be unlocked in memory and the lock count reset.

  • During a memory lockout, if the user attempts to authenticate with the correct password (using authentication modules other than LDAP and Membership), a User does not have profile in this realm error. message is returned rather than a User is not active. error.

  • If the Failure URL attribute in the user’s profile is defined, neither the lockout warning message nor the message indicating that the account has been locked will be displayed; the user will be redirected to the defined URL.

For information on the account lockout attributes, see Configuring the Core Authentication Service.

Authentication Service Failover

The Authentication Service will automatically redirect an authentication request to a second server if the primary server becomes unavailable because of a hardware or software problem, or if the server is temporarily shut down. The Authentication Service URL is first passed to an instance of the com.sun.identity.authentication.AuthContext class. If this URL is unavailable, locations defined in the Servers attribute of the primary OpenSSO Enterprise instance's configuration will be checked and, if one is available, an authentication context will be created for this second instance of OpenSSO Enterprise through the authentication failover mechanism. (For more information, see Servers and Sites in Sun OpenSSO Enterprise 8.0 Administration Reference.)

Failing the Servers and Sites check, the authentication context queries the Platform list from a server where the Naming service is available This platform list is automatically created when multiple instances of OpenSSO Enterprise are installed (generally, for failover purposes) sharing a one instance of the configuration data store.

For example, if the platform list contains URLs for Server1, Server2 and Server3, then the authentication context will loop through Server1 , Server2 and Server3 until authentication succeeds on one of them.

The platform list may not always be obtained from the same server, as it depends on the availability of the Naming service. Furthermore, Naming service failover may occur first. Multiple Naming service URLs are specified in the Naming Service. The first available Naming service URL will be used to identify the server, which will contain the list of servers (in its platform server list) on which authentication failover will occur.

Mapping Fully Qualified Domain Names

Fully Qualified Domain Name (FQDN) mapping enables the Authentication Service to take corrective action in the case where a user may have typed in an incorrect URL (such as specifying a partial host name or IP address to access protected resources). FQDN mapping is enabled by modifying the com.sun.identity.server.fqdnMap attribute in the in the Advance Properties for Servers and Sites. For more information, see Advanced in Sun OpenSSO Enterprise 8.0 Administration Reference. The format for specifying this property is:

com.sun.identity.server.fqdnMap[invalid-name ]=valid-name

The value invalid-name would be a possible invalid FQDN host name that may be typed by the user, and valid-name would be the actual host name to which the filter will redirect the user. Any number of mappings can be specified as long as they conform to the stated requirements. If this property is not set, the user would be sent to the default server name configured in the server_name property.

Possible Uses For FQDN Mapping

This property can be used for creating a mapping for more than one host name which may be the case if applications hosted on a server are accessible by more than one host name. This property can also be used to configure OpenSSO Enterprise to not take corrective action for certain URLs. For example, if no redirect is required for users who access applications by using an IP address, this feature can be implemented by specifying a map entry such as:

com.sun.identity.server.fqdnMap[IP address ]=IP address.

Note –

If more than one mapping is defined, ensure that there are no overlapping values in the invalid FQDN name. Failing to do so may result in the application becoming inaccessible.

Using Persistent Cookies

A persistent cookie is one that continues to exist after the web browser is closed, allowing a user to login with a new browser session without having to re-authenticate. The cookie value is a 3DES-encrypted string containing the userDN, realm name, authentication module name, maximum session time, idle time, and cache time. To Use Persistent Cookies contains the procedure to enable this function.

Note –

Persistent cookies do not work with the Distributed Authentication User Interface or when using Cross Domain Single Sign-on. If enabled and using either of these options, a regular cookie will be created.

ProcedureTo Use Persistent Cookies

Programmatically, Persistent Cookie mode can be enabled by using the setPersistentCookieOn() method of the com.sun.identity.authentication.spi.AMLoginModule class. See Chapter 1, Using the Authentication Service API and SPI, in Sun OpenSSO Enterprise 8.0 Developer’s Guide for more information.

  1. Configure the Authentication Service to use persistent cookies in the Core authentication module.

    Enable the Persistent Cookie Mode attribute and modify, if necessary, the value of the Persistent Cookie Maximum Time attribute. See To Modify Core Authentication Properties By Realm for the procedure.

  2. (Optional) Modify the persistent cookie name using this sub procedure.

    1. Click Servers and Sites under the Configuration tab.

    2. Click Default Server Settings.

    3. Click Advanced.

    4. Change the value of the com.iplanet.am.pcookie.name property.

      The default value is DProPCookie.

    5. Click Save.

  3. Append the iPSPCookie=yes parameter to the User Interface Login URL.


    http://OpenSSO-machine-name.domain:port/opensso/UI/Login?realm=hr&iPSPCookie=yes

    Once the user authenticates using this URL, if the browser is closed, the user can open a new browser window and will be redirected to the console without re-authenticating. This will work until the time defined as the value of Persistent Cookie Maximum Time elapses.

Upgrading Sessions

The Authentication Service enables you to upgrade a valid session token based on a second, successful authentication performed by the same user to the same realm. If a user with a valid session token attempts to authenticate to a resource secured by his current realm and this second authentication request is successful, the session is updated with the properties based on the new authentication. If the authentication fails, the user’s current session is returned without an upgrade. If the user with a valid session attempts to authenticate to a resource secured by a different realm, the user will receive a message asking whether they would like to authenticate to the new realm. The user can, at this point, maintain the current session or attempt to authenticate to the new realm. Successful authentication to the new realm will result in the old session being destroyed and a new one being created.

During session upgrade, if a login page times out, redirection to the original success URL will occur. Timeout values are determined based on:

Caution – Caution –

The values of Invalidate Session Max Time and Maximum Session Time should be greater than the value of the timeout attribute; otherwise, the valid session information during session upgrade will be lost and URL redirection to the previous successful URL will fail.

Sharing User Credentials Among Authentication Modules (Shared State)

The Java Authentication and Authorization Service (on which the Authentication Service is built) has an option to enable shared state which allows for sharing of both the user ID and password between authentication modules. For example, assume an authentication chain is configured as follows:

For this authentication process, the user would be presented with an LDAP login page to enter a user ID and password. Assuming successful LDAP authentication, these credentials would then be passed to the Data Store module on the backend; the user would not see a Data Store login page. If Data Store authentication is successful, the user would be redirected to the appropriate page.

The shared state is enabled by entering the appropriate options to the authentication module as you configure an authentication chain. The options are:

iplanet-am-auth-shared-state-enabled

This option enables the use of a shared state map.

iplanet-am-auth-store-shared-state-enabled

This option enables the storage of credentials to a shared state map.

iplanet-am-auth-shared-state-behavior-pattern

To prevent a user from having to enter the user ID and password twice for authentication, set this option to useFirstPass for all modules in the chain (except the first). tryFirstPass (the default value) would prompt for new credentials if the shared state credentials failed

After a commit, an abort or a logout, the shared state will be cleared. To add shared state options to an authentication module in an authentication chain, see Creating Authentication Chains.

Redirecting Users After Authentication

Redirecting users to a particular URL upon successful or failed authentication can be configured in a number of ways.

Information on how the precedence of redirection URLs is determined is in Initiating the Authentication Type.

Configuring Multiple LDAP Authentication Modules (Legacy Mode)

As a form of failover or to configure multiple values for an attribute when the OpenSSO Enterprise console only provides one value field, an administrator can define multiple LDAP authentication module configurations under one realm. Although these additional configurations are not visible from the console, they work in conjunction with the primary configuration if an initial search for the requesting user’s authorization is not found. For example, one realm can define a search through LDAP servers for authentication in two different domains or it can configure multiple user naming attributes in one domain. For the latter, which has only one text field in the console, if a user is not found using the primary search criteria, the LDAP module will then search using the second scope. Following are the steps to configure additional LDAP configurations.

ProcedureTo Configure Multiple LDAP Authentication Modules

Any additional LDAP authentication module configurations created using this procedure can not be seen or modified using the OpenSSO Enterprise console.

  1. Write an XML file including the complete set of attributes and new values needed for a second (or third) LDAP authentication configuration.

    The available LDAP authentication module attributes are in the amAuthLDAP.xml file. Any or all of these attributes can be used for the additional LDAP configurations defined in this step. Following is an example of a sub-configuration file that includes values for all attributes available to the LDAP authentication configuration.


    >
<!--
  Before adding subConfiguration load the schema with
GlobalConfiguration defined and replace corresponding
 serviceName and subConfigID in this sample file OR load
 serviceConfigurationRequests.xml before loading this sample
-->
<Requests>
<realmRequests DN="dc=iplanet,dc=com">
    <AddSubConfiguration subConfigName = "ssc"
        subConfigId = "serverconfig"
        priority = "0" serviceName="iPlanetAMAuthLDAPService">
              <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-server"/>
            <Value>vbrao.red.iplanet.com:389</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-base-dn"/>
            <Value>dc=iplanet,dc=com</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="planet-am-auth-ldap-bind-dn"/>
            <Value>cn=amldapuser,ou=DSAME Users,dc=iplanet,dc=com</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-bind-passwd"/>
            <Value>plain text password</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-user-naming-attribute"/>
            <Value>uid</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-user-search-attributes"/>
            <Value>uid</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-search-scope"/>
            <Value>SUBTREE</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-ssl-enabled"/>
            <Value>false</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-return-user-dn"/>
            <Value>true</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-auth-level"/>
            <Value>0</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-server-check"/>
            <Value>15</Value>
        </AttributeValuePair>
    </AddSubConfiguration>
</realmRequests>
</Requests>

  2. Load the XML file using the ssoadm command line tool.