An authentication service confirms the identity of a user or a client application. This chapter describes how to configure authentication in OpenAM.

Authentication Access management is about controlling access to resources. OpenAM plays a role similar to border control at an international airport. Instead of having each and every airline company deal with access to each destination, all airlines redirects passengers to border control. Border control then determines who each passenger is according to passport credentials. Border control also checks whether the identified passenger is authorized to fly to the destination corresponding to the ticket, perhaps based on visa credentials. Then, at the departure gate, an agent enforces the authorization from border control, allowing the passenger to board the plane as long as the passenger has not gotten lost, or tried to board the wrong plane, or swapped tickets with someone else. Thus, border control handles access management at the airport. OpenAM is most frequently used to protect web-accessible resources. Users browse to a protected web application page. Rather than have the web application manage user access itself, an agent in the server where the web application runs redirects the user to OpenAM for access management. OpenAM determines who the user is, and whether the user has the right to access the protected page. OpenAM then redirects the user back to the protected page, this time with authorization that the agent can check. The agent enforces the authorization from OpenAM, letting through the user with the right to access the page. Thus, OpenAM handles access management to web resources. Notice that OpenAM basically needs to determine two things for access management: who the user is; whether the user has access to the protected page. Authentication is the term meaning the determination of who a user is. This chapter covers how to set up the authentication process. Authorization is the term meaning determination whether a user has access to a protected resource. Authorization is covered later. To process authentication, OpenAM obtains credentials from the user or client application authenticating, based on the mechanisms defined to validate credentials and complete the authentication. In other words, how a user authenticates differs depending on the situation. Passengers for international flights authenticate with passports and visas. Passengers for domestic flights might authenticate with an identity card or a driver's license. Customers withdrawing cash from an ATM authenticate with a card and a PIN. Authentication Modules Authentication Chains As the authentication process depends on the situation, OpenAM allows you to configure authentication processes and then configure how they are applied depending on the situation. OpenAM uses authentication modules to handle different ways of authenticating. Basically, each authentication module handles one way of obtaining and verifying credentials. When a single set of credentials is not enough, or alternate sets of credentials can be used, you can choose to chain modules together. In OpenAM, this is called authentication chaining. When you chain authentication modules, you can configure each module as required, optional, requisite, or sufficient.The four terms, required, optional, requisite, and sufficient, come from JAAS, the Java standard for authentication and authorization. When a required module fails, the rest of the chain is processed, but the authentication fails. A required module might be used for login with email and password, but then fall through to another module to handle new users who have not yet signed up. When an optional module fails, authentication continues. An optional module might be used to permit a higher level of access if the user can present a X.509 certificate for example. When a requisite module fails, authentication fails and authentication processing stops. A requisite module might be used with exclusive SSO. When a sufficient succeeds, authentication is successful and later modules in the chain are skipped. You could set Windows Desktop SSO as sufficient, so authenticated Windows users are let through, whereas web users have to traverse another authentication module such as one requiring an email address and a password. Authentication Levels With OpenAM, you can further set authentication levels per module, with higher levels being used typically to allow access to more restricted resources. The OpenAM SPIs also let you develop your own authentication modules, and post-authentication plugins. Client applications can specify the authentication level, module, user, and authentication service to use among those you have configured. As described later in this guide, you can use realms to organize which authentication process applies for different applications or different domains, perhaps managed by different people. OpenAM leaves the authentication process flexible so that you can adapt how it works to your situation. Although at first the number of choices can seem daunting, now that you understand the basic process, you begin to see how choosing authentication modules and arranging them in authentication chains lets you use OpenAM to protect access to a wide range of applications used in your organization.

The OpenAM console provides two places where the OpenAM administrator can configure authentication modules. Under Configuration > Authentication, you configure available modules for use throughout OpenAM. What you set up here is inherited for use elsewhere. Under Access Control > Realm Name > Authentication, you configure modules for your realm. What you set up at this level inherits from the global configuration, but you can override what is inherited. You can also add your own modules if necessary. Individual module configuration depends completely on what the module does. Configuring the module that connects to Active Directory over LDAP to authenticate a user using user name and password requires connection information and details about where to search for users, whereas configuring the HOTP module for one-time password authentication requires information about the password length and the mail server or SMS gateway for sending the password during authentication. One parameter that all modules have is Authentication Level. You change Authentication Level from 0 to a positive integer in order to indicate those modules are seen as more secure. Then you configure authorization to require a minimum authentication level required to access protected resources.

OpenAM connects to Active Directory over Lightweight Directory Access Protocol (LDAP). OpenAM provides separate Active Directory and LDAP modules to make it easier for you to use both Active Directory and also another directory service in an authentication chain. Authentication Active Directory ssoadm service name: sunAMAuthADService Primary Active Directory Server Secondary Active Directory Server The default port for LDAP is 389. If you are connecting to Active Directory over SSL, the default port for LDAP/SSL is 636. To allow users to change passwords through OpenAM, Active Directory requires that you connect over SSL. If you want to use SSL or TLS for security, then scroll down to enable SSL/TLS Access to Active Directory Server. Make sure that OpenAM can trust the Active Directory certificate when using this option. OpenAM first attempts to contact primary servers. If no primary server is available, then OpenAM attempts to contact secondaries. When authenticating users from a directory server that is remote from OpenAM, set both the primary and secondary server values. ssoadm attributes: primary is iplanet-am-auth-ldap-server; secondary is iplanet-am-auth-ldap-server2 DN to Start User Search LDAP data is organized hierarchically, a bit like a file system on Windows or UNIX. More specific DNs likely result in better performance. When configuring the module for a particular part of the organization, you can perhaps start searches from a specific organizational unit such as OU=sales,DC=example,DC=com. If multiple entries exist with identical search attribute values, make this value specific enough to return only one entry. ssoadm attribute: iplanet-am-auth-ldap-base-dn Bind User DN, Bind User Password If OpenAM stores attributes in Active Directory, for example to manage account lockout, or if Active Directory requires that OpenAM authenticate in order to read users' attributes, then OpenAM needs the DN and password to authenticate to Active Directory. The default is amldapuser. If the administrator authentication chain (default: ldapService) has been configured to include only the Active Directory module, then make sure that the password is correct before you logout. If it is incorrect, you will be locked out. If you do get locked out, you can login with the super user DN, which by default is uid=amAdmin,ou=People,OpenAM-deploy-base, where OpenAM-deploy-base was set during OpenAM configuration. ssoadm attributes: iplanet-am-auth-ldap-bind-dn and iplanet-am-auth-ldap-bind-passwd Attributes, Filter, Scope LDAP searches for user entries return entries with attribute values matching the filter you provide. For example if you search under CN=Users,DC=example,DC=com with a filter "(MAIL=bjensen@example.com)", then the directory returns the entry that has MAIL=bjensen@example.com. In this example the attribute used to search for a user is mail. Multiple attribute values mean the user can authenticate with any one of the values. For example, if you have both uid and mail, then Barbara Jensen can authenticate with either bjensen or bjensen@example.com. Should you require a more complex filter for performance, you add that to the User Search Filter text box. For example, if you search on mail and add User Search Filter (objectClass=inetOrgPerson), then OpenAM uses the resulting search filter (&(mail=address)(objectClass=inetOrgPerson)), where address is the mail address provided by the user. Scope OBJECT means search only the entry specified as the DN to Start User Search, whereas ONELEVEL means search only the entries that are directly children of that object. SUBTREE means search the entry specified and every entry under it. ssoadm attributes: iplanet-am-auth-ldap-user-naming-attribute, iplanet-am-auth-ldap-user-search-attributes, iplanet-am-auth-ldap-search-filter, and iplanet-am-auth-ldap-search-scope SSL Access to Active Directory Server If you enable SSL, OpenAM must be able to trust Active Directory certificates, either because the Active Directory certificates were signed by a CA whose certificate is already included in the trust store used by the container where OpenAM runs, or because you imported the certificates into the trust store. ssoadm attribute: iplanet-am-auth-ldap-ssl-enabled Return User DN to Authenticate When enabled, and OpenAM uses Active Directory as the user store, the module returns the DN rather than the User ID, so the bind for authentication can be completed without a search to retrieve the DN. ssoadm attribute: iplanet-am-auth-ldap-return-user-dn Active Directory Server Check Interval Used by the failover mechanism. Specifies the number of minutes between checks whether a previously unavailable Active Directory has become available again. ssoadm attribute: iplanet-am-auth-ldap-server-check User Creation Attributes This list lets you map (external) attribute names from Active Directory to (internal) attribute names used by OpenAM. ssoadm attribute: iplanet-am-ldap-user-creation-attr-list Authentication Level ssoadm attribute: sunAMAuthADAuthLevel

The Adaptive Risk module is designed to assess risk during authentication so that OpenAM can determine whether to require the user to complete further authentication steps. After configuring the Adaptive Risk module, insert it in your authentication chain with criteria set to sufficient as shown in the following example. Including the Adaptive Risk module in an authentication chain With the Adaptive Risk module as sufficient, OpenAM continues to the next module in the chain should the Adaptive Risk module return failure. In the example authentication chain shown, OpenAM has users authenticate first using the LDAP module providing a user ID and password combination. Upon success, OpenAM calls the Adaptive Risk module. The Adaptive Risk module assesses the risk based on your configured parameters. If the Adaptive Risk module calculates a total score below the threshold you set, the module returns success, and OpenAM finishes authentication processing without requiring further credentials. Otherwise the Adaptive Risk module evaluates the score to be above the risk threshold, and returns failure. OpenAM then calls the HOTP module, requiring the user to authenticate with a one-time password delivered to her by email or by SMS to her mobile phone. When you configure the Adaptive Risk module to save cookies and profile attributes after successful authentication, OpenAM performs the save as post-authentication processing, only after the entire authentication chain returns success. You must set up OpenAM to save the data as part of post-authentication processing by editing the authentication chain to add org.forgerock.openam.authentication.modules.adaptive.Adaptive to the list of post authentication plugins. Authentication Adaptive risk ssoadm service name: sunAMAuthAdaptiveService Authentication Level ssoadm attribute: openam-auth-adaptive-auth-level Adaptive Threshold Risk threshold score. If the sum of the Scores is greater than the threshold, the Adaptive Risk module returns failure. ssoadm attribute: openam-auth-adaptive-auth-threshold Failed Authentication Check When enabled, check the user profile for authentication failures since the last successful login. This check therefore requires OpenAM to have access to the user profile, and Account Lockout to be enabled (otherwise OpenAM does not record authentication failures). ssoadm attribute: openam-auth-adaptive-failure-check Score Value to add to the total score if the user fails the Failed Authentication Check. ssoadm attribute: openam-auth-adaptive-failure-score Invert Result When selected, add the Score to the total score if the user passes the Failed Authentication Check. ssoadm attribute: openam-auth-adaptive-failure-invert IP Range Check When enabled, check whether the client IP address is within one of the specified IP Ranges. ssoadm attribute: openam-auth-adaptive-ip-range-check IP Range Specifies a list of IP ranges either in CIDR-style notation (x.x.x.x/YY) or as a range from one address to another (x.x.x.x:y.y.y.y, meaning from x.x.x.x to y.y.y.y). Currently supports only IPv4. ssoadm attribute: openam-auth-adaptive-ip-range-range Score Value to add to the total score if the user fails the IP Range Check. ssoadm attribute: openam-auth-adaptive-ip-range-score Invert Result When selected, add the Score to the total score if the user passes the IP Range Check. ssoadm attribute: openam-auth-adaptive-ip-range-invert IP History Check When enabled, check whether the client IP address matches one of the known values stored on the profile attribute you specify. This check therefore requires that OpenAM have access to the user profile. ssoadm attribute: openam-auth-adaptive-ip-history-check Count to Save Specifies how many IP address values to retain on the profile attribute you specify. Default: 5 ssoadm attribute: openam-auth-ip-adaptive-history-count Profile Attribute Name Name of the user profile attribute on which to store known IP addresses. Default: iphistory ssoadm attribute: openam-auth-adaptive-ip-history-attribute Save Successful IP Address When enabled, save new client IP addresses to the known IP address list following successful authentication. ssoadm attribute: openam-auth-adaptive-ip-history-save Score Value to add to the total score if the user fails the IP History Check. ssoadm attribute: openam-auth-adaptive-ip-history-score Invert Result When selected, add the Score to the total score if the user passes the IP History Check. ssoadm attribute: openam-auth-adaptive-ip-history-invert Cookie Value Check When enabled, check whether the client browser request has the specified cookie and optional cookie value. ssoadm attribute: openam-auth-adaptive-known-cookie-check Cookie Name Specifies the name of the cookie for which OpenAM checks when you enable the Cookie Value Check. ssoadm attribute: openam-auth-adaptive-known-cookie-name Cookie Value Specifies the value of the cookie for which OpenAM checks. If no value is specified, OpenAM does not check the cookie value. ssoadm attribute: openam-auth-adaptive-known-cookie-value Save Cookie Value on Successful Login When enabled, save the cookie as specified in the client's browser following successful authentication. If no Cookie Value is specified, the value is set to 1. ssoadm attribute: openam-auth-adaptive-known-cookie-save Score Value to add to the total score if user passes the Cookie Value Check. ssoadm attribute: openam-auth-adaptive-known-cookie-score Invert Result When selected, add the Score to the total score if the user passes the Cookie Value Check. ssoadm attribute: openam-auth-adaptive-known-cookie-invert Device Registration Cookie Check When enabled, check whether the client browser request has the specified cookie with the correct device registration identifier as the value. ssoadm attribute: openam-auth-adaptive-device-cookie-check Cookie Name Specifies the name of the cookie for the Device Registration Cookie Check. Default: Device ssoadm attribute: openam-auth-adaptive-device-cookie-name Save Device Registration on Successful Login When enabled, save the specified cookie with a hashed device identifier value in the client's browser following successful authentication. ssoadm attribute: openam-auth-adaptive-device-cookie-save Score Value to add to the total score if the user fails the Device Registration Cookie Check. ssoadm attribute: openam-auth-adaptive-device-cookie-score Invert Result When selected, add the Score to the total score if the user passes the Device Registration Cookie Check. ssoadm attribute: openam-auth-adaptive-device-cookie-invert Time Since Last Login Check When enabled, check whether the client browser request has the specified cookie that holds the encrypted last login time, and check that the last login time is more recent than a maximum number of days you specify. ssoadm attribute: openam-auth-adaptive-time-since-last-login-check Cookie Name Specifies the name of the cookie holding the encrypted last login time value. ssoadm attribute: openam-auth-adaptive-time-since-last-login-cookie-name Max Time Since Last Login Specifies a threshold age of the last login time in days. If the client's last login time is more recent than the number of days specified, then the client successfully passes the check. ssoadm attribute: openam-auth-adaptive-time-since-last-login-value Save Time of Successful Login When enabled, save the specified cookie with the current time encrypted as the last login value in the client's browser following successful authentication. ssoadm attribute: openam-auth-adaptive-time-since-last-login-save Score Value to add to the total score if the user fails the Time Since Last Login Check. ssoadm attribute: openam-auth-adaptive-time-since-last-login-score Invert Result When selected, add the Score to the total score if the user passes the Time Since Last Login Check. ssoadm attribute: openam-auth-adaptive-time-since-last-login-invert Profile Risk Attribute Check When enabled, check whether the user profile contains the specified attribute and value. ssoadm attribute: openam-auth-adaptive-risk-attribute-check Attribute Name Specifies the attribute to check on the user profile for the specified value. ssoadm attribute: openam-auth-adaptive-risk-attribute-name Attribute Value Specifies the value to match on the profile attribute. If the attribute is multi-valued, a single match is sufficient to pass the check. ssoadm attribute: openam-auth-adaptive-risk-attribute-value Score Value to add to the total score if the user fails the Profile Risk Attribute Check. ssoadm attribute: openam-auth-adaptive-risk-attribute-score Invert Result When selected, add the Score to the total score if the user passes the Profile Risk Attribute Check. ssoadm attribute: openam-auth-adaptive-risk-attribute-invert Geolocation Country Code Check When enabled, check whether the client IP address location matches a country specified in the Valid Country Codes list. ssoadm attribute: forgerock-am-auth-adaptive-geo-location-check Geolocation Database location Path to GeoIP data file used to convert IP addresses to country locations. Use the binary .dat file format, rather than .csv. ssoadm attribute: openam-auth-adaptive-geo-location-database Valid Country Codes Specifies the list of country codes to match. ssoadm attribute: openam-auth-adaptive-geo-location-values. Use | to separate multiple values. Score Value to add to the total score if the user fails the Geolocation Country Code Check. ssoadm attribute: openam-auth-adaptive-geo-location-score Invert Result When selected, add the Score to the total score if the user passes the Geolocation Country Code Check. ssoadm attribute: openam-auth-adaptive-geo-location-invert Request Header Check When enabled, check whether the client browser request has the specified header with the correct value. ssoadm attribute: openam-auth-adaptive-req-header-check Request Header Name Specifies the name of the request header for the Request Header Check. ssoadm attribute: openam-auth-adaptive-req-header-name Request Header Value Specifies the value of the request header for the Request Header Check. ssoadm attribute: openam-auth-adaptive-req-header-value Score Value to add to the total score if the user fails the Request Header Check. ssoadm attribute: openam-auth-adaptive-req-header-score Invert Result When selected, add the Score to the total score if the user passes the Request Header Check. ssoadm attribute: openam-auth-adaptive-req-header-invert

This module lets you track and manage anonymous users, perhaps forcing further authentication later when a user moves to access resources that require more protection. Authentication Anonymous ssoadm service name: iPlanetAMAuthAnonymousService Valid Anonymous Users Specifies valid anonymous user IDs in addition to the default. ssoadm attribute: iplanet-am-auth-anonymous-users-list Default Anonymous User Name Specifies the user ID assigned by the module if the Valid Anonymous Users list is empty. Default: anonymous ssoadm attribute: iplanet-am-auth-anonymous-default-user-name Case Sensitive User IDs Whether case matters for anonymous user IDs. ssoadm attribute: iplanet-am-auth-anonymous-case-sensitive Authentication Level ssoadm attribute: iplanet-am-auth-anonymous-auth-level

X.509 digital certificates can enable secure authentication without the need for user names and passwords or other credentials. Certificate authentication can be handy to manage authentication by applications. If all certificates are signed by a recognized Certficate Authority (CA), then you might get away without additional configuration. If you need to look up public keys of OpenAM clients, this module can also look up public keys in an LDAP directory server. When you store certificates and certificate revocation lists (CRL) in an LDAP directory service, you must configure both how to access the directory service and also how to look up the certificates and CRLs, based on the fields in the certificates that OpenAM clients present to authenticate. Access to the LDAP server and how to search for users is similar to LDAP module configuration as in . The primary difference is that, unlike for LDAP configuration, OpenAM retrieves the user identifier from a field in the certificate that the client application presents, then uses that identifier to search for the LDAP directory entry that holds the certificate, which should match the certificate presented. For example, if the Subject field of a typical certificate has a DN C=FR, O=Example Corp, CN=Barbara Jensen, and Barbara Jensen's entry in the directory has cn=Barbara Jensen, then you can use CN=Barbara Jensen from the Subject DN to search for the entry with cn=Barbara Jensen in the directory. Authentication X509 certificate based ssoadm service name: iPlanetAMAuthCertService Match Certificate in LDAP When enabled, OpenAM searches for a match for the user's certificate in the LDAP directory. If a match is found and not revoked according to a CRL or OCSP validation, then authentication succeeds. ssoadm attribute: iplanet-am-auth-cert-check-cert-in-ldap Subject DN Attribute Used to Search LDAP for Certificates Indicates which attribute and value in the certificate Subject DN is used to find the LDAP entry holding the certificate. ssoadm attribute: iplanet-am-auth-cert-attr-check-ldap Match Certificate to CRL When enabled, OpenAM checks whether the certificate has been revoked according to a CRL in the LDAP directory. ssoadm attribute: iplanet-am-auth-cert-check-crl Issuer DN Attribute Used to Search LDAP for CRLs Indicates which attribute and value in the certificate Issuer DN is used to find the CRL in the LDAP directory. ssoadm attribute: iplanet-am-auth-cert-attr-check-crl HTTP Parameters for CRL Update Your certificate authority should provide the URL to use here, from which OpenAM can get CRL updates. ssoadm attribute: iplanet-am-auth-cert-param-get-crl Match CA Certificate to CRL When enabled, OpenAM checks the CRL against the CA certificate to ensure it has not been compromised. ssoadm attribute: sunAMValidateCACert OCSP Validation Enable this to use Online Certificate Status Protocol (OCSP) instead of CRLs to check certificates' revocation status. If you enable this, you also must configure OSCP for OpenAM under Configuration > Server and Sites > Default Server Settings, or Configuration > Server and Sites > Server Name > Security. ssoadm attribute: iplanet-am-auth-cert-check-ocsp LDAP Server Where Certificates are Stored The default port for LDAP is 389. If you are connecting to the directory service over SSL, the default port for LDAP/SSL is 636. When a secure connection, scroll down to enable Use SSL/TLS for LDAP Access. ssoadm attribute: iplanet-am-auth-cert-ldap-provider-url LDAP Search Start DN Valid base DN for the LDAP search, such as dc=example,dc=com. ssoadm attribute: iplanet-am-auth-cert-start-search-loc LDAP Server Principal User, LDAP Server Principal Password If OpenAM stores attributes in the LDAP directory, for example to manage account lockout, or if the LDAP directory requires that OpenAM authenticate in order to read users' attributes, then OpenAM needs the DN and password to authenticate to the LDAP directory. ssoadm attributes: iplanet-am-auth-cert-principal-user, and iplanet-am-auth-cert-principal-passwd Use SSL for LDAP Access If you use SSL for LDAP access, OpenAM must be able to trust the LDAP server certificate. ssoadm attribute: iplanet-am-auth-cert-use-ssl Certificate Field Used to Access User Profile If the user profile is in a different entry from the user certificate, then this can be different from subject DN attribute used to find the entry with the certificate. When you select other, provide an attribute name in the Other Certificate Field Used to Access User Profile text box. ssoadm attribute: iplanet-am-auth-cert-user-profile-mapper SubjectAltNameExt Value Type to Access User Profile Use this if you want to look up the user profile from an RFC 822 style name, or a User Principal Name as used in Active Directory. ssoadm attribute: iplanet-am-auth-cert-user-profile-mapper-ext Trusted Remote Hosts Hosts trusted to send certificates to OpenAM, such as load balancers doing SSL termination, or OpenAM distributed authentication UI instances. ssoadm attribute: iplanet-am-auth-cert-gw-cert-auth-enabled HTTP Header Name for Client Certificate If you configure trusted hosts, specify the HTTP header name for the client certificate inserted by the trusted host. ssoadm attribute: sunAMHttpParamName Authentication Level ssoadm attribute: iplanet-am-auth-cert-auth-level

The Core module is a sort of meta-module. The Core module lets you set up the list of modules available, and specify what types of client applications can authenticate with which modules. It also lets you configure connection pools for access to directory servers, and whether to retain objects used during authentication for use during logout. Furthermore, the Core module lets you set defaults used when configuring authentication in a particular realm. Authentication Core ssoadm service name: iPlanetAMAuthService Pluggable Authentication Module Classes Add class names for custom authentication modules to this list. ssoadm attribute: iplanet-am-auth-authenticators Supported Authentication Modules for Clients This list serves to limit what types of authentication modules can be used with specify types of client applications. The client type is an arbitary string, such as the default genericHTML, which is set by OpenAM when the Client Detection Service is enabled. ssoadm attribute: iplanet-am-auth-supported-auth-modules LDAP Connection Pool Size, Default LDAP Connection Pool Size Sets a minimum and maximum number of LDAP connections in the pool for connecting to a directory server. When tuning for production, start with 10:65 (10 minimum, 65 maximum). Explicit settings for specific servers override the default. This attribute is for LDAP and Membership authentication services only. This connection pool is different than the SDK connection pool configured in serverconfig.xml. ssoadm attributes: iplanet-am-auth-ldap-connection-pool-size , and iplanet-am-auth-ldap-connection-pool-default-size Remote Auth Security Require the authenticating application to send its SSOToken. This allows the Authentication Service to obtain the username and password associated with the application. ssoadm attribute: sunRemoteAuthSecurityEnabled Keep Post Process Objects for Logout Processing, Keep Authentication Module Objects for Logout Processing When enabled, retain objects used to process authentication or post authentication operations in the user session until the user logs out. ssoadm attributes: sunAMAuthKeepPostProcessInstances, and sunAMAuthKeepAuthModuleIntances User Profile Whether a user profile needs to exist in the user data store, or should be created on successful authentication. Dynamic Specifies that on successful authentication the Authentication Service creates a user profile if one does not already exist. OpenAM then issues the SSOToken. OpenAM creates the user profile in the user data store configured for the realm. Dynamic with User Alias Specifies that on successful authentication the Authentication Service creates a user profile that contains the User Alias List attribute which defines one or more aliases that for mapping a user's multiple profiles. Ignored Specifies that a user profile is not required for the Authentication Service to issue an SSOToken after a successful authentication. Required Specifies that on successful authentication the user must have a user profile in the user data store configured for the realm in order for the Authentication Service to issue an SSOToken. ssoadm attribute: iplanet-am-auth-dynamic-profile-creation Administrator Authentication Configuration Defines the authentication chain used by administrators when the process needs to be different from the authentication chain defined for end users. The authentication chain must first be created before it is displayed as an option in this attribute's drop down list. ssoadm attribute: iplanet-am-auth-admin-auth-module User Profile Dynamic Creation Default Roles Specifies the Distinguished Name (DN) of a role to be assigned to a new user whose profile is created when either of the Dynamic options is selected under the User Profile attribute. There are no default values. The role specified must be within the realm for which the authentication process is configured. This role can be either an OpenAM or Sun DSEE role, but it cannot be a filtered role. If you wish to automatically assign specific services to the user, you have to configure the Required Services attribute in the User Profile. ssoadm attribute: iplanet-am-auth-default-role Persistent Cookie Mode Determines whether users can return to their authenticated session after restarting the browser. When enabled, the persistent cookie can be used to reauthenticate until the persistent cookie expires (as specified by the value of the Persistent Cookie Maximum Time attribute), or until the user explicitly logs out. By default, the Authentication Service uses only memory cookies (expires when the browser is closed). The client must explicitly request a persistent cookie by adding iPSPCookie=yes as a parameter to the login URL. OpenAM sets a DProPCookie as described in . ssoadm attribute: iplanet-am-auth-persistent-cookie-mode Persistent Cookie Maximum Time Specifies the interval after which a persistent cookie expires. The interval begins when the user's session is successfully authenticated. The maximum value is 2147483647 (in seconds, so a bit more than 68 years). The field accepts any integer value less than the maximum. ssoadm attribute: iplanet-am-auth-persistent-cookie-time Alias Search Attribute Name After a user is successfully authenticated, the user's profile is retrieved. This field specifies a second LDAP attribute to use in a search for the profile if a search using the first LDAP attribute fails to locate a matching user profile. Primarily, this attribute is used when the user identification returned from an authentication module is not the same as that specified in User Naming Attribute. For example, a RADIUS server might return abc1234 but the user name is abc. There is no default value for this attribute. The field takes any valid LDAP attribute. ssoadm attribute: iplanet-am-auth-alias-attr-name Default Authentication Locale Specifies the default language subtype to be used by the Authentication Service. The default value is en_US. ssoadm attribute: iplanet-am-auth-locale Organization Authentication Configuration Defines the default authentication chain used by the realm's users. The authentication chain must first be created before it is displayed as an option in this attribute's drop down list. ssoadm attribute: iplanet-am-auth-org-config Login Failure Lockout Mode Selecting this attribute enables a physical lockout. Physical lockout will inactivate an LDAP attribute (defined in the Lockout Attribute Name property) in the user's profile. This attribute works in conjunction with several other lockout and notification attributes. ssoadm attribute: iplanet-am-auth-login-failure-lockout-mode Login Failure Lockout Count Defines the number of attempts that a user has to authenticate, within the time interval defined in Login Failure Lockout Interval, before being locked out. ssoadm attribute: iplanet-am-auth-login-failure-count Login Failure Lockout Interval Defines the time in minutes during which failed login attempts are counted. If one failed login attempt is followed by a second failed attempt, within this defined lockout interval time, the lockout count starts, and the user is locked out if the number of attempts reaches the number defined in Login Failure Lockout Count. If an attempt within the defined lockout interval time proves successful before the number of attempts reaches the number defined in Login Failure Lockout Count, the lockout count is reset. ssoadm attribute: iplanet-am-auth-login-failure-duration Email Address to Send Lockout Notification Specify one (or more) email address(es) to which notification is sent if a user lockout occurs. Separate multiple addresses with spaces, and append |locale|charset to addresses for recipients in non-English locales. ssoadm attribute: iplanet-am-auth-lockout-email-address Warn User After N Failures The number of authentication failures after which OpenAM displays a warning message that the user will be locked out. ssoadm attribute: iplanet-am-auth-lockout-warn-user Login Failure Lockout Duration Defines how many minutes a user must wait after a lockout before attempting to authenticate again. Entering a value greater than 0 enables memory lockout and disables physical lockout. Memory lockout means the user's account is locked in memory for the number of minutes specified. The account is unlocked after the time period has passed. ssoadm attribute: iplanet-am-auth-lockout-duration Lockout Duration Multiplier Defines a value with which to multiply the value of the Login Failure Lockout Duration attribute for each successive lockout. For example, if Login Failure Lockout Duration is set to 3 minutes, and the Lockout Duration Multiplier is set to 2, the user is locked out of the account for 6 minutes. Once the 6 minutes has elapsed, if the user again provides the wrong credentials, the lockout duration is then 12 minutes. With the Lockout Duration Multiplier, the lockout duration is incrementally increased based on the number of times the user has been locked out. ssoadm attribute: sunLockoutDurationMultiplier Lockout Attribute Name Defines the LDAP attribute used for physical lockout. The default value is inetuserstatus, although the field in the OpenAM console is empty. The Lockout Attribute Value field must also contain an appropriate value. ssoadm attribute: iplanet-am-auth-lockout-attribute-name Lockout Attribute Value Specifies the action to take on the attribute defined in Lockout Attribute Name. The default value is inactive, although the field in the OpenAM console is empty. The Lockout Attribute Name field must also contain an appropriate value. ssoadm attribute: iplanet-am-auth-lockout-attribute-value Invalid Attempts Data Attribute Name Specifies the LDAP attribute used to hold the number of failed authentication attempts towards Login Failure Lockout Count. ssoadm attribute: sunAMAuthInvalidAttemptsDataAttrName Default Success Login URL Accepts a list of values that specifies where users are directed after successful authentication. The format of this attribute is client-type|URL although the only value you can specify at this time is a URL which assumes the type HTML. The default value is /openam/console. Values that do not specify HTTP have that appended to the deployment URI. ssoadm attribute: iplanet-am-auth-login-success-url Default Failure Login URL Accepts a list of values that specifies where users are directed after authentication has failed. The format of this attribute is client-type|URL although the only value you can specify at this time is a URL which assumes the type HTML. Values that do not specify HTTP have that appended to the deployment URI. ssoadm attribute: iplanet-am-auth-login-failure-url Authentication Post Processing Classes Specifies one or more Java classes used to customize post authentication processes for successful or unsuccessful logins. The Java class must implement the com.sun.identity.authentication.spi.AMPostAuthProcessInterface OpenAM interface. A .jar containing the post processing class belongs in the WEB-INF/lib directory of the deployed OpenAM instance. If you do not build a .jar, add the class files under WEB-INF/classes. For deployment, add the .jar or classes into a custom OpenAM .war file. ssoadm attribute: iplanet-am-auth-post-login-process-class Generate UserID Mode When enabled, the Membership module generates a list of alternate user identifiers if the one entered by a user during the self-registration process is not valid or already exists. The user identifiers are generated by the class specified in the Pluggable User Name Generator Class property. ssoadm attribute: iplanet-am-auth-username-generator-enabled Pluggable User Name Generator Class Specifies the name of the class used to generate alternate user identifiers when Generate UserID Mode is enabled. The default value is com.sun.identity.authentication.spi.DefaultUserIDGenerator. ssoadm attribute: iplanet-am-auth-username-generator-class Identity Types Lists the type or types of identities for which OpenAM searches. ssoadm attribute: sunAMIdentityType Pluggable User Status Event Classes Specifies one or more Java classes used to provide a callback mechanism for user status changes during the authentication process. The Java class must implement the com.sun.identity.authentication.spi.AMAuthCallBack OpenAM interface. OpenAM supports account lockout and password changes. OpenAM supports password changes through the LDAP authentication module, and so the feature is only available for the LDAP module. A .jar containing the user status event class belongs in the WEB-INF/lib directory of the deployed OpenAM instance. If you do not build a .jar, add the class files under WEB-INF/classes. For deployment, add the .jar or classes into a custom OpenAM .war file. ssoadm attribute: sunAMUserStatusCallbackPlugins Store Invalid Attempts in Data Store Enables the storage of information regarding failed authentication attempts as the value of the Invalid Attempts Data Attribute Name in the user data store. In order to store data in this attribute, the OpenAM schema has to be loaded. Information stored includes number of invalid attempts, time of last failed attempt, lockout time and lockout duration. Storing this information in the identity repository allows it to be shared among multiple instances of OpenAM. ssoadm attribute: sunStoreInvalidAttemptsInDS Module Based Authentication Enables users to authenticate using module-based authentication. Otherwise, all attempts at authentication using the module=module-name login parameter result in failure. ssoadm attribute: sunEnableModuleBasedAuth User Attribute Mapping to Session Attribute Enables the authenticating user's identity attributes (stored in the identity repository) to be set as session properties in the user's SSOToken. The value takes the format User-Profile-Attribute|Session-Attribute-Name. If Session-Attribute-Name is not specified, the value of User-Profile-Attribute is used. All session attributes contain the am.protected prefix to ensure that they cannot be edited by the Client SDK. For example, if you define the user profile attribute as mail and the user's email address (available in the user session) as user.mail, the entry for this attribute would be mail|user.mail. After a successful authentication, the SSOToken.getProperty(String) method is used to retrieve the user profile attribute set in the session. The user's email address is retrieved from the user's session using the SSOToken.getProperty("am.protected.user.mail") method call. Properties that are set in the user session using User Attribute Mapping to Session Attributes can not be modified (for example, SSOToken.setProperty(String, String)). This results in an SSOException. Multi-value attributes, such as memberOf, are listed as a single session variable with a | separator. ssoadm attribute: sunAMUserAttributesSessionMapping Valid goto URL domains List external domains to which clients can be redirected after authentication. ssoadm attribute: iplanet-am-auth-valid-goto-domains Default Authentication Level The level set here applies when no authentication level has been specified in the Authentication Level field for a realm. ssoadm attribute: iplanet-am-auth-default-auth-level

The Data Store authentication module allows a login using the Identity Repository of the realm to authenticate users. Using the Data Store module removes the requirement to write an authentication plug-in module, load, and then configure the authentication module if you need to authenticate against the same data store repository. Additionally, you do not need to write a custom authentication module where flat-file authentication is needed for the corresponding repository in that realm. Yet, the Data Store module is generic. It does not implement data store-specific capabilities such as the password policy and password reset features provided by LDAP modules. Therefore the Data Store module returns failure when such capabilities are invoked. Authentication Data Store ssoadm service name: sunAMAuthDataStoreService ssoadm attributes: amAuthDataStore, and sunAMAuthDataStoreAuthLevel

The Federation authentication module is used by a service provider to create a user session after validating single sign-on protocol messages. This authentication module is used by the SAML, SAMLv2, ID-FF, and WS-Federation protocols. Authentication Federation ssoadm service name: sunAMAuthFederationService ssoadm attribute: sunAMAuthFederationAuthLevel

The HMAC One-Time Password authentication module works together with the Data Store module to retrieve a user's mail address or telephone number to send a one-time password to complete authentication. To use HOTP you set up an authentication chain with the Data Store module as the requisite first module, and the HOTP module as the second requisite module. When authentication succeeds against the Data Store module, OpenAM passes the Email Address and Telephone Number attributes from the user profile to the HOTP module. For the HOTP module to use either attribute, the Email Address must contain a valid email address, or the Telephone Number must contain a valid SMS telephone number such as 18285551212@txt.att.net. Authentication HMAC One-Time Password (HOTP) ssoadm service name: sunAMAuthHOTPService SMS Gateway Implementation Class Change this if you must customize the SMS gateway implementation. The default class sends an SMS or email, depending on the configuration. ssoadm attribute: sunAMAuthHOTPSMSGatewayImplClassName SMTP Host Name Host name of the mail server supporting Simple Message Transfer Protocol for electronic mail. ssoadm attribute: sunAMAuthHOTPSMTPHostName SMTP Host Port The default SMTP port is 25, 465 (when connecting over SSL). ssoadm attribute: sunAMAuthHOTPSMTPHostPort SMTP User Name User name for OpenAM to connect to the mail server. ssoadm attribute: sunAMAuthHOTPSMTPUserName SMTP User Password Password for OpenAM to connect to the mail server. ssoadm attribute: sunAMAuthHOTPSMTPUserPassword SMTP Connection If OpenAM connects to the mail server securely, OpenAM must be able to trust the server certificate. ssoadm attribute: sunAMAuthHOTPSMTPSSLEnabled Email From Address The From: address when sending a one-time password by mail. ssoadm attribute: sunAMAuthHOTPSMTPFromAddress One Time Password Validity Length (in minutes) One-time passwords are valid for 5 minutes after they are generated by default. ssoadm attribute: sunAMAuthHOTPPasswordValidityDuration One Time Password Length (in digits) Set the length of the one-time password to 6 or 8 digits. ssoadm attribute: sunAMAuthHOTPPasswordLength One Time Password Delivery Send the one-time password by SMS, by mail, or both. ssoadm attribute: sunAMAuthHOTPasswordDelivery Authentication Level ssoadm attribute: sunAMAuthHOTPAuthLevel

HTTP basic authentication takes a user name and password from HTTP authentication and tries authentication against the backend module in OpenAM, depending on what you configure as the Backend Module Name. Authentication HTTP Basic ssoadm service name: iPlanetAMAuthHTTPBasicService Backend Module Name Specifies the module that checks the user credentials. ssoadm attribute: iplanet-am-auth-http-basic-module-configured Authentication Level ssoadm attribute: iplanet-am-auth-httpbasic-auth-level

The Java Database Connectivity (JDBC) module lets OpenAM connect to a database such as MySQL or Oracle DB to authenticate users. Authentication JDBC ssoadm service name: sunAMAuthJDBCService Connection Type Choose Connection pool is retrieved via JNDI to connect using the Java Naming and Diretory Interface connection pool supported by the web container in which OpenAM runs. Choose Non-persistent JDBC connection to connect directly through the JDBC driver. ssoadm attribute: sunAMAuthJDBCConnectionType Connection Pool JNDI Name When using Connection pool is retrieved via JNDI, this specifies the pool. How you configure connection pooling depends on the web container where you run OpenAM. Refer to the documentation for your web container for instructions on setting up connection pooling. ssoadm attribute: sunAMAuthJDBCJndiName JDBC Driver When using Non-persistent JDBC connection, this specifies the JDBC driver provided by the database. The .jar containing the JDBC driver belongs in the WEB-INF/lib directory of the deployed OpenAM instance, and so you should add it to a custom OpenAM .war file that you deploy. ssoadm attribute: sunAMAuthJDBCDriver JDBC URL When using Non-persistent JDBC connection, this specifies the URL to connect to the database. ssoadm attribute: sunAMAuthJDBCUrl Connect This User to Database Specify the user name to open the database connection. ssoadm attribute: sunAMAuthJDBCDbuser Password for Connecting to Database Specify the password for the user opening the database connection. ssoadm attribute: sunAMAuthJDBCDbpassword Password Column String Specify the database column name where passwords are stored. ssoadm attribute: sunAMAuthJDBCPasswordColumn Prepared Statement Specify the SQL query to return the password corresponding to the user to authenticate. ssoadm attribute: sunAMAuthJDBCStatement Class to Transform Password Syntax Specify the class that transforms the password retrieved to the same format as provided by the user. The default class expects the password in clear text. Custom classes must implement the JDBCPasswordSyntaxTransform interface. ssoadm attribute: sunAMAuthJDBCPasswordSyntaxTransformPlugin Authentication Level ssoadm attribute: sunAMAuthJDBCAuthLevel

OpenAM connects to directory servers using Lightweight Directory Access Protocol (LDAP). To build an easy-to-manage, high performance, pure Java, open source directory service, try OpenDJ directory services. Authentication LDAP ssoadm service name: iPlanetAMAuthLDAPService Primary LDAP Server Secondary LDAP Server Directory servers generally use built-in data replication for high availability. Thus a directory service likely consists of a pool of replicas to which OpenAM can connect to retrieve and update directory data. You set up primary and secondary servers in case a replica is down due to maintenance or to a problem with a particular server. Set one primary and optionally one secondary directory server for each OpenAM server. For the current OpenAM server, specify each directory server as a host:port combination. For other OpenAM servers in the deployment, you can specify each directory server as server-name|host:port, where server-name is the Server Name of the OpenAM server from the list under Configuration > Servers and Sites, and host:port identifies the directory server. When authenticating users from a directory service that is remote from OpenAM, set both the primary and secondary server values. The default port for LDAP is 389. If you are connecting to the directory over SSL, the default port for LDAP/SSL is 636. If you want to use SSL or TLS for security, then scroll down to enable SSL/TLS Access to LDAP Server. Make sure that OpenAM can trust the servers' certificates when using this option. ssoadm attributes: primary is iplanet-am-auth-ldap-server, secondary is iplanet-am-auth-ldap-server2, and iplanet-am-auth-ldap-ssl-enabled DN to Start User Search LDAP data is organized hierarchically, a bit like a file system on Windows or UNIX. More specific DNs likely result in better search performance. When configuring the module for a particular part of the organization, you can perhaps start searches from a specific organizational unit such as ou=sales,dc=example,dc=com. If multiple entries exist with identical search attribute values, make this value specific enough to return only one entry. ssoadm attribute: iplanet-am-auth-ldap-base-dn Bind User DN, Bind User Password If OpenAM stores attributes in the directory, for example to manage account lockout, or if the directory requires that OpenAM authenticate in order to read users' attributes, then OpenAM needs the DN and password to authenticate to the directory. The default is cn=Directory Manager. Make sure that password is correct before you logout. If it is incorrect, you will be locked out. If this should occur, you can login with the super user DN, which by default is uid=amAdmin,ou=People,OpenAM-deploy-base, where OpenAM-deploy-base you set during OpenAM configuration. ssoadm attributes: iplanet-am-auth-ldap-bind-dn, iplanet-am-auth-ldap-bind-passwd Attributes, Filter, Scope LDAP searches for user entries return entries with attribute values matching the filter you provide. For example if you search under ou=people,dc=example,dc=com with a filter "(mail=bjensen@example.com)", then the directory returns the entry that has mail=bjensen@example.com. In this example the attribute used to search for a user is mail. Multiple attribute values mean the user can authenticate with any one of the values. For example, if you have both uid and mail, then Barbara Jensen can authenticate with either bjensen or bjensen@example.com. Should you require a more complex filter for performance, you add that to the User Search Filter text box. For example, if you search on mail and add User Search Filter (objectClass=inetOrgPerson), then OpenAM uses the resulting search filter (&(mail=address)(objectClass=inetOrgPerson)), where address is the mail address provided by the user. Scope OBJECT means search only the entry specified as the DN to Start User Search, whereas ONELEVEL means search only the entries that are directly children of that object. SUBTREE means search the entry specified and every entry under it. ssoadm attributes: iplanet-am-auth-ldap-user-naming-attribute, iplanet-am-auth-ldap-user-search-attributes, iplanet-am-auth-ldap-search-filter, and iplanet-am-auth-ldap-search-scope Return User DN to Authenticate When enabled, and OpenAM uses the directory service as the user store, the module returns the DN rather than the rather than the User ID, so the bind for authentication can be completed without a search to retrieve the DN. ssoadm attribute: iplanet-am-auth-ldap-return-user-dn LDAP Server Check Interval Specifies the number of minutes between checks that the primary LDAP server continues to respond. ssoadm attribute: iplanet-am-auth-ldap-server-check User Creation Attributes This list lets you map (external) attribute names from Active Directory to (internal) attribute names used by OpenAM. ssoadm attribute: iplanet-am-ldap-user-creation-attr-list Minimum Password Length Specify the minimum acceptable password length. ssoadm attribute: iplanet-am-auth-ldap-min-password-length Trust All Server Certificates When enabled, blindly trust server certificates, including self-signed test certificates. ssoadm attribute: iplanet-am-auth-ldap-ssl-trust-all LDAP Behera Password Policy Support When enabled, support interoperability with servers that implement the Internet-Draft, Password Policy for LDAP Directories. ssoadm attribute: iplanet-am-auth-ldap-behera-password-policy-enabled Authentication Level ssoadm attribute: iplanet-am-auth-ldap-auth-level

The Membership module permits self-registration for new users. You can then have OpenAM create new user profiles in the identity repository. Authentication Membership (& self-registration) ssoadm service name: iPlanetAMAuthMembershipService Minimum Password Length Specify the minimum acceptable number of characters in the password provided during self-registration. ssoadm attribute: iplanet-am-auth-membership-min-password-length Default User Roles Specifies the Distinguished Name (DN) of a role to be assigned to a new user whose profile is created. There are no default values. The role specified must be within the realm for which the authentication process is configured. This role can be either an OpenAM or Sun DSEE role, but it cannot be a filtered role. If you wish to automatically assign specific services to the user, you have to configure the Required Services attribute in the User Profile. ssoadm attribute: iplanet-am-auth-membership-default-roles User Status After Registration If you choose Inactive, then the new user has no access to services until an administrator activates the account. ssoadm attribute: iplanet-am-auth-membership-default-user-status Authentication Level ssoadm attribute: iplanet-am-auth-membership-auth-level

The Mobile Station Integrated Services Digital Network (MSISDN) authentication module enables non-interactive authentication using a mobile subscriber ISDN associated with a terminal such as a mobile phone. The module checks the subscriber ISDN against the value found on a user's entry in an LDAP directory service. Authentication MSISDN ssoadm service name: sunAMAuthMSISDNService Trusted Gateway IP Address Specifies a list of IP addresses of trusted clients that can access MSIDSN modules. Either restrict the clients allowed to access the MSISDN module by add each IPv4 address here, or leave the list empty to allow all clients to access the module. If you specify the value none, no clients are allowed access. ssoadm attribute: sunAMAuthMSISDNTrustedGatewayList MSISDN Number Argument Specifies a list of parameter names that identify which parameters to search in the request header or cookie header for the MSISDN number. For example, if you define x-Cookie-Param, AM_NUMBER, and COOKIE-ID, the MSISDN authentication service checks those parameters for the MSISDN number. ssoadm attribute: sunAMAuthMSISDNParameterNameList LDAP Server and Port The default port for LDAP is 389. If you are connecting to the directory over SSL, the default port for LDAP/SSL is 636. If you want to use SSL or TLS for security, then scroll down to enable SSL/TLS Access to LDAP. Make sure that OpenAM can trust the servers' certificates when using this option. ssoadm attribute: sunAMAuthMSISDNLdapProviderUrl LDAP Start Search DN Specify the DN of the entry where the search for the user's MSISDN number should start. ssoadm attribute: sunAMAuthMSISDNBaseDn Attribute To Use To Search LDAP Specify the name of the attribute in the user's profile that contains the MSISDN number to search for the user. The default is sunIdentityMSISDNNumber. ssoadm attribute: sunAMAuthMSISDNUserSearchAttribute LDAP Server Principal User If OpenAM must authenticate to the directory server in order to search, then specify the bind DN. The default is cn=amldapuser,ou=DSAME Users,dc=example,dc=com. ssoadm attribute: sunAMAuthMSISDNPrincipalUser LDAP Server Principal Password Specify the password corresponding to the bind DN. ssoadm attribute: sunAMAuthMSISDNPrincipalPasswd SSL/TLS for LDAP Access If you choose to use SSL or TLS for security, then make sure that OpenAM can trust the servers' certificates. ssoadm attribute: sunAMAuthMSISDNUseSsl MSISDN Header Search Attribute Specify the headers to use for searching the request for the MSISDN number. Cookie Header tells OpenAM to search the cookie. Request Header tells OpenAM to search the request header. Request Parameter tells OpenAM to search the request parameters. ssoadm attribute: sunAMAuthMSISDNHeaderSearch LDAP Attribute Used to Retrieve User Profile Specify the LDAP attribute that is used during a search to return the user profile for MSISDN authentication service. The default is uid. ssoadm attribute: sunAMAuthMSISDNUserNamingAttribute Return User DN to DataStore Enable this option only when the OpenAM directory is the same as the directory configured for MSISDN searches. When enabled, this option allows the authentication module to return the DN instead of the User ID. OpenAM thus does not need to perform an additional search with the user ID to find the user's entry. ssoadm attribute: sunAMAuthMSISDNReturnUserDN Authentication Level ssoadm attribute: sunAMAuthMSISDNAuthLevel

The OAuth 2.0 authentication module lets OpenAM authenticate clients of OAuth resource servers. References in this section are to the Internet-Draft The OAuth 2.0 Authorization Protocol. Authentication OAuth 2.0 ssoadm service name: sunAMAuthOAuthService Client ID OAuth client_id as described in section 2.1 of the Internet-Draft. ssoadm attribute: iplanet-am-auth-oauth-client-id Client Secret OAuth client_secret as described in section 2.1 of the Internet-Draft. ssoadm attribute: iplanet-am-auth-oauth-client-secret Authentication Endpoint URL URL to the end point handling OAuth authentication. ssoadm attribute: iplanet-am-auth-oauth-auth-service Access Token Endpoint URL URL to the end point handling access tokens as described in section 3.2 of the Internet-Draft. ssoadm attribute: iplanet-am-auth-oauth-token-service User Profile Service URL User profile URL that returns profile information in JSON format. ssoadm attribute: iplanet-am-auth-oauth-user-profile-service Scope Comma separated list of user profile attributes that the application requires. ssoadm attribute: iplanet-am-auth-oauth-scope Proxy URL URL to the oauthproxy.jsp file, by default part of OpenAM. ssoadm attribute: iplanet-am-auth-oauth-sso-proxy-url Account Mapper Class implementing account mapping. Default: org.forgerock.openam.authentication.modules.oauth2.DefaultAccountMapper ssoadm attribute: org-forgerock-auth-oauth-account-mapper Account Mapper Configuration Map of OAuth Provider user account attributes used to find the local profile of the authenticated user, with values in the form provider-attr=local-attr. ssoadm attribute: org-forgerock-auth-oauth-account-mapper-configuration Attribute Mapper Class implementing attribute mapping. Default: org.forgerock.openam.authentication.modules.oauth2.DefaultAttributeMapper ssoadm attribute: org-forgerock-auth-oauth-attribute-mapper Attribute Mapper Configuration Map of OAuth Provider user account attributes to local user profile attributes, with values in the form provider-attr=local-attr. ssoadm attribute: org-forgerock-auth-oauth-attribute-mapper-configuration Save attributes in the session When enabled, add the mapped attributes to the session saved. ssoadm attribute: org-forgerock-auth-oauth-save-attributes-to-session-flag Email attribute in OAuth2 Response Specifies the attribute identifying email address in the response from the profile service in the OAuth provider. This setting is used to send an email address with an activation code for accounts created dynamically. ssoadm attribute: org-forgerock-auth-oauth-mail-attribute Create account if it does not exist When enabled, if the user profile does not exist, optionally retrieve a password and activation code from the user, and then create the profile. ssoadm attribute: org-forgerock-auth-oauth-createaccount-flag Prompt for password setting and activation code When enabled, the user sets a password, receives an activation code by email. The user must correctly set both in order for the account to be created. ssoadm attribute: org-forgerock-auth-oauth-prompt-password-flag Map to anonymous user When enabled, map the OAuth authenticated user to the anoymous user you specify. No account is created, even if Create account if it does not exist is enabled. ssoadm attribute: org-forgerock-auth-oauth-map-to-anonymous-flag Anonymous User Specifies an anonymous user that exists in the current realm. ssoadm attribute: org-forgerock-auth-oauth-anonymous-user OAuth 2.0 Provider logout service Specifies the optional URL of the OAuth Provider. ssoadm attribute: org-forgerock-auth-oauth-logout-service-url Logout options Specifies whether not to log the user out without prompting from the OAuth Provider on logout, to log the user out without prompting, or to prompt the user regarding whether to logout from the OAuth provider. ssoadm attribute: org-forgerock-auth-oauth-logout-behaviour SMTP Gateway Implementation class Class to interact with the mail server. Default: org.forgerock.openam.authentication.modules.oauth2.DefaultEmailGatewayImpl ssoadm attribute: org-forgerock-auth-oauth-email-gwy-impl SMTP host Host name of the mail server. ssoadm attribute: org-forgerock-auth-oauth-smtp-hostname SMTP port SMTP port number for the mail server. ssoadm attribute: org-forgerock-auth-oauth-smtp-port SMTP User Name If the mail server requires authentication to send mail, specifies the user name. ssoadm attribute: org-forgerock-auth-oauth-smtp-username SMTP User Password If the mail server requires authentication to send mail, specifies the password. ssoadm attribute: org-forgerock-auth-oauth-smtp-password SMTP SSL Enabled When enabled, connect to the mail server over SSL. OpenAM must be able to trust the SMTP server certificate. ssoadm attribute: org-forgerock-auth-oauth-smtp-ssl_enabled SMTP From address Specifies the message sender address, such as no-reply@example.com. ssoadm attribute: org-forgerock-auth-oauth-smtp-email-from Authentication Level ssoadm attribute: iplanet-am-auth-oauth-auth-level

The Remote Authentication Dial-In User Service (RADIUS) module lets OpenAM authenticate users against RADIUS servers. Authentication RADIUS ssoadm service name: iPlanetAMAuthRadiusService Server 1 Specify the IP address or fully qualified domain name of the primary RADIUS server. The default is 127.0.0.1 (localhost loopback). ssoadm attribute: iplanet-am-auth-radius-server1 Server 2 Specify the IP address or fully qualified domain name of the secondary RADIUS server. The default is 127.0.0.1. ssoadm attribute: iplanet-am-auth-radius-server2 Shared Secret Specify the shared secret for RADIUS authentication. The shared secret should be as secure as a well-chosen password. ssoadm attribute: iplanet-am-auth-radius-secret Port Number Specify the RADIUS server port. Default is 1645. ssoadm attribute: iplanet-am-auth-radius-server-port Timeout Specify how many seconds to wait for the RADIUS server to respond. The default value is 3 seconds. ssoadm attribute: iplanet-am-auth-radius-timeout Health check interval Used for failover. Specify how often OpenAM performs a health check on a previously unavailable RADIUS server by sending an invalid authentication request. Default: 5 minutes ssoadm attribute: openam-auth-radius-healthcheck-interval Authentication Level ssoadm attribute: iplanet-am-auth-radius-auth-level

The Secure Attribute Exchange (SAE) module lets OpenAM authenticate a user who has already authenticated with an entity that can vouch for the user to OpenAM, so that OpenAM creates a session for the user. This module is useful in virtual federation, where an existing entity instructs the local OpenAM instance to use federation protocols to transfer authentication and attribute information to a partner application. Authentication Secure Attribute Exchange (SAE) ssoadm service name: sunAMAuthSAEService ssoadm attribute: sunAMAuthSAEAuthLevel

The SecurID module lets OpenAM authenticate users with RSA Authentication Manager software and RSA SecurID authenticators. Authentication SecurID ssoadm service name: iPlanetAMAuthSecurIDService ACE/Server Configuration Path Specify the directory in which the SecurID ACE/Server sdconf.rec file is located, which by default is expected under the configuration directory for OpenAM, such as $HOME/openam/openam/auth/ace/data. The directory must exist before OpenAM can use SecurID authentication. ssoadm attribute: iplanet-am-auth-securid-server-config-path Authentication Level ssoadm attribute: iplanet-am-auth-securid-auth-level

The Windows Desktop SSO module uses Kerberos authentication. The user presents a Kerberos token to OpenAM through the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol. The Windows Desktop SSO authentication module enables desktop single sign on such that a user who has already authenticated with a Kerberos Key Distribution Center can authenticate to OpenAM without having to provide the login information again. Users might need to set up Integrated Windows Authentication in Internet Explorer to benefit from single sign on when logged on to a Windows desktop. Authentication Kerberos Authentication Windows Desktop SSO ssoadm service name: iPlanetAMAuthWindowsDesktopSSOService Service Principal Specify the Kerberos principal for authentication in the following format. HTTP/host.domain@dc-domain-name Here, host and domain correspond to the host and domain names of the OpenAM instance, and dc-domain-name is the domain name of the Windows Kerberos domain controller server. The dc-domain-name can differ from the domain name for OpenAM. You set up the account on the Windows domain controller, creating a computer account for OpenAM and associating the new account with a service provider name. ssoadm attribute: iplanet-am-auth-windowsdesktopsso-principal-name Keytab File Name Specify the full path of the keytab file for the Service Principal. You generate the keytab file using the Windows ktpass utility. ssoadm attribute: iplanet-am-auth-windowsdesktopsso-keytab-file Kerberos Realm Specify the Kerberos Key Distribution Center realm. For the Windows Kerberos service this is the domain controller server domain name. ssoadm attribute: iplanet-am-auth-windowsdesktopsso-kerberos-realm Kerberos Server Name Specify the fully qualified domain name of the Kerberos Key Distribution Center server, such as that of the domain controller server. ssoadm attribute: iplanet-am-auth-windowsdesktopsso-kdc Return Principal with Domain Name When enabled, OpenAM automatically returns the Kerberos principal with the domain controller's domain name during authentication. ssoadm attribute: iplanet-am-auth-windowsdesktopsso-returnRealm Authentication Level ssoadm attribute: iplanet-am-auth-windowsdesktopsso-auth-level

The Windows NT module lets OpenAM authenticate against a Microsoft Windows NT server. This module requires that you install a Samba client in a bin directory under the OpenAM configuration directory such as $HOME/openam/openam/bin. Authentication Windows NT ssoadm service name: iPlanetAMAuthNTService Authentication Domain Specify the Windows domain name to which users belong. ssoadm attribute: iplanet-am-auth-nt-domain Authentication Host Specify the NetBIOS name of the Windows NT host to which to authenticate users. ssoadm attribute: iplanet-am-auth-nt-host Samba Configuration File Name Specify the full path to the Samba configuration file. ssoadm attribute: iplanet-am-auth-samba-config-file-name Authentication Level ssoadm attribute: iplanet-am-auth-nt-auth-level

The Web Service Security (WSSAuth) module lets OpenAM validate a user name, password combination received as an authentication token in a request from a Web Service Client to a Web Service Provider. Authentication WSSAuth ssoadm service name: sunAMAuthWSSAuthModuleService User search attribute Specify a user attribute to search for a user. Default is uid. ssoadm attribute: sunWebservicesUserSearchAttribute User realm Specify the realm to which users belong. For the OpenAM Security Token Service, this is /. ssoadm attribute: sunWebServicesUserRealm User password attribute Specify the password attribute or that of the password equivalent. The default is userPassword. ssoadm attribute: sunWebservicesUserPasswordAttribute Authentication Level ssoadm attribute: sunWebservicesAuthenticationLevel

Authentication Chains Once you have configured authentication modules, and added the modules to the list of module instances, you can configure authentication chains. Authentication chains let you handle situations where alternative modules are needed, or where a single set of credentials is not sufficient. On the Access Control tab page of the OpenAM console, click the realm for which to create the authentication chain. On the Authentication tab page for the realm, scroll to the bottom of the page, and click the New button in the Authentication Chaining table. Give the new authentication chain a name, and add instances of the modules to use in the chain. Assign at least criteria (optional, required, requisite, sufficient) as described above in . You can also configure where OpenAM redirects the user upon successful and failed authentication, and plug in your post-authentication processing classes as necessary. If you need modules in the chain to share user credentials, then set options for the module. iplanet-am-auth-shared-state-enabled Set iplanet-am-auth-shared-state-enabled=true to allow subsequent modules in the authentication chain to use the credentials, such as user name and password, captured by this module. (Default: true) iplanet-am-auth-store-shared-state-enabled Set iplanet-am-auth-store-shared-state-enabled=true to store the captured credentials. Shared state is cleared when the user successfully authenticates, quits the chain, or logs out. (Default: false) iplanet-am-auth-shared-state-behavior-pattern Set iplanet-am-auth-shared-state-behavior-pattern=tryFirstPass (the default) to try authenticating with the captured password. If authentication fails, then OpenAM prompts the user for the credentials again. Set iplanet-am-auth-shared-state-behavior-pattern=useFirstPass to authenticate with the captured password. If authentication fails, then the module fails. For example, consider a chain with two modules sharing credentials according to the default settings. The first module in the chain has the option iplanet-am-auth-shared-state-enabled=true, and criteria REQUIRED. The second module in the chain has options iplanet-am-auth-shared-state-enabled=true, iplanet-am-auth-shared-state-behavior-pattern=tryFirstPass, and criteria REQUIRED. A successful authentication sequence happens as follows. The user enters her credentials for the first module, successfully authenticating. The first module shares the credentials with the second module, successfully authenticating the user without prompting again for her credentials, unless the credentials for the first module do not successfully authenticate here to the second module. Save your work. Before you select the default chain for users, and especially for administrators, test the authentication chain first. For example, http://openam.example.com:8080/openam/UI/Login?service=NewChain. If you cannot log in, then go back and fix the authentication chain's configuration before making it the default. On the Access Control tab page of the OpenAM console, click the realm for which to set the default authentication chain. If necessary, on the Authentication tab page for the realm, adjust the drop-down lists for Organization Authentication Configuration and Administrator Authentication Configuration to the appropriate authentication chains. The Organization Authentication Configuration serves when users access /openam/UI/Login. The Administrator Authentication Configuration serves when users access /openam/console. You can set these independently to separate administrative login from user login. For example, you can change the default user chain, but leave the default administrator chain as is to avoid locking yourself out as administrator. By default, amadmin can login at /openam/UI/Login. You can change that for your deployment. Save your work.

This section explains how to connect to OpenAM for user authentication by adding parameters to the login URL when testing your configuration. The base URL to authenticate to OpenAM points to /UI/Login under the deployment URL, such as http://openam.example.com:8080/openam/UI/Login. The base URL to logout is similar, for example http://openam.example.com:8080/openam/UI/Logout. You can, however, specify parameters in the query string of the URL to request a specific authentication configuration. For example, http://openam.example.com:8080/openam/UI/Login?module=LDAP requests that OpenAM use the LDAP authentication module. OpenAM accepts the following parameters in the query string. With the exception of IDToken parameters, use no more than one occurrence of each. arg=newsession Request that OpenAM end the user's current session and start a new session. Example: http://openam.example.com:8080/openam/UI/Login?arg=newsession authlevel Request that OpenAM authenticate the user using a module with at least the specified authentication level that you have configured. As this parameter determines authentication module selection, do not use it with module, service, or user. Example: http://openam.example.com:8080/openam/UI/Login?authlevel=1 ForceAuth If ForceAuth=true, request that OpenAM force the user to authenticate even if she already has a valid session. On successful authentication, OpenAM updates the session token. Example: http://openam.example.com:8080/openam/UI/Login?ForceAuth=true goto On successful authentication, or successful logout, request that OpenAM redirect the user to the specified location. Values must be URL encoded. Example: http://openam.example.com:8080/openam/UI/Login?goto=http%3A%2F%2Fwww.example.com%2Fsuccess.html gotoOnFail On authentication failure, request that OpenAM redirect the user to the specified location. Values must be URL encoded. Example: http://openam.example.com:8080/openam/UI/Login?goto=http%3A%2F%2Fwww.example.com%2Ffailure.html IDToken1, IDToken2, ..., IDTokenN Pass the specified credentials as IDToken parameters in the URL. The IDToken credentials map to the fields in the login page for the authentication module, such as IDToken1 as user ID and IDToken2 as password for basic user name, password authentication. The order depends on the callbacks in login page for the module; IDTokenN represents the Nth callback of the login page. Example: http://openam.example.com:8080/openam/UI/Login?IDToken1=bjensen&IDToken2=hifalutin iPSPCookie=yes Request that OpenAM return a persistent cookie that remains in the browser after the browser is closed, allowing the user to login again without being prompted for credentials. This only works if you have configured persistent cookie mode for the realm where the user logs in. Example: http://openam.example.com:8080/openam/UI/Login?iPSPCookie=yes OpenAM sets an DProPCookie that persists until expiry. The following screen shot shows an example. DProPCookie shown in the browser An alternative persistent cookie mechanism extends the lifetime of the normal iPlanetDirectoryPro using the advanced server settings, openam.session.persist_am_cookie or openam.session.allow_persist_am_cookie, and com.iplanet.am.cookie.timeToLive. To set the mechanism globally for the server, browse in the OpenAM console to Configuration > Servers and Sites > Server Name > Advanced, and then set openam.session.persist_am_cookie to true and com.iplanet.am.cookie.timeToLive to the cookie lifetime in seconds. To allow users to use this mechanism on a per-session basis, browse in the OpenAM console to Configuration > Servers and Sites > Server Name > Advanced, and then set openam.session.allow_persist_am_cookie to true and com.iplanet.am.cookie.timeToLive to the cookie lifetime in seconds. (If the OpenAM .war deployed does not include the console, set these properties in the .properties configuration file.) Also configure the session properties either globally under Configuration > Global > Session > Dynamic Attributes, or per realm under Access Control > Realm Name > Services > Session. Then, to request the cookie, use openam.session.persist_am_cookie=Yes as one of the query string parameters in the login URL. locale Request that OpenAM display the user interface in the specified, supported locale. Locale can also be set in the user's profile, in the HTTP header from her browser, configured in OpenAM, and so on. Example: http://openam.example.com:8080/openam/UI/Login?locale=fr module Request that OpenAM use the authentication module instance as configured for the realm where the user is authenticating. As this parameter determines authentication module selection, do not use it with authlevel, service, or user. Example: http://openam.example.com:8080/openam/UI/Login?module=DataStore realm Request that OpenAM authenticate the user to the specified realm. Example: http://openam.example.com:8080/openam/UI/Login?realm=sales service Request that OpenAM authenticate the user with the specified authentication chain. As this parameter determines authentication module selection, do not use it with authlevel, module, or user. Example: http://openam.example.com:8080/openam/UI/Login?service=ExternalChain user Request that the user, specified by her OpenAM universal ID, authenticate according to the chain specified in her profile. As this parameter determines authentication module selection, do not use it with authlevel, module, or service. Example: http://openam.example.com:8080/openam/UI/Login?user=admin