As described in the Configuring AM for Authentication, you configure authentication by realm at the following locations in the AM console:
Under Realms > Realm Name > Authentication > Settings
Under Realms > Realm Name > Authentication > Modules
You can configure default values for authentication modules under Configure > Authentication using the same attributes you use to configure authentication modules per realm. These defaults are used when a module is created for a specific realm.
The core attributes page includes some fields that are not available under Realms > Realm Name > Authentication > Settings. Because attributes set under Configure > Authentication > Core Attributes apply on a server level, the changes you make here will apply to all realms. Attributes set by Realm only apply to the realm that you specify. The Authentication Module Defaults list under Configure > Authentication shows all existing types of modules available for configuration, including any customized modules you have added.
The following section describes the properties you can configure on the Global tab under Configure > Authentication > Core Attributes. The properties on the other tabs on that page are described in "Core Authentication Attributes".
The following properties are available under the Global Attributes tab:
- Pluggable Authentication Module Classes
Lists the authentication modules classes available to AM. If you have custom authentication modules, add classes to this list that extend from the
For more information about custom authentication modules, see "Creating a Custom Authentication Module".
- LDAP Connection Pool Size
Sets a minimum and a maximum number of LDAP connections to be used by any authentication module that connects to a specific directory server. This connection pool is different than the SDK connection pool configured in
This attribute is for LDAP and Membership authentication modules only.
- Default LDAP Connection Pool Size
Sets the default minimum and maximum number of LDAP connections to be used by any authentication module that connects to any directory server. This connection pool is different than the SDK connection pool configured in
When tuning for production, start with 10 minimum, 65 maximum. For example,
This attribute is for LDAP and Membership authentication modules only.
- Remote Auth Security
When enabled, AM requires the authenticating application to send its SSO token. This allows AM to obtain the username and password associated with the application.
- Keep Post Process Objects for Logout Processing
When enabled, AM stores instances of post-processing classes into the user session. When the user logs out, the original post-processing classes are called instead of new instances. This may be required for special logout processing.
Enabling this setting increases the memory usage of AM.
The following properties are available under the Core tab:
- Administrator Authentication Configuration
Specifies the default authentication chain used when an administrative user, such as
amAdmin, logs in to the AM console.
- Organization Authentication Configuration
Specifies the default authentication chain used when a non-administrative user logs in to AM.
The following properties are available under the User Profile tab:
Specifies whether a user profile needs to exist in the user data store, or should be created on successful authentication. The possible values are:
After successful authentication, AM creates a user profile if one does not already exist. AM then issues the SSO token. AM creates the user profile in the user data store configured for the realm.
createAlias. Dynamic with User Alias.
After successful authentication, AM creates a user profile that contains the
User Alias Listattribute, which defines one or more aliases for mapping a user's multiple profiles.
After successful authentication, AM issues an SSO token regardless of whether a user profile exists in the data store. The presence of a user profile is not checked.
Any functionality which needs to map values to profile attributes, such as SAML or OAuth 2.0, will not operate correctly if the User Profile property is set to
After successful authentication, the user must have a user profile in the user data store configured for the realm in order for AM to issue an SSO token.
iplanet-am-auth-dynamic-profile-creation. Set this attribute's value to one of the following:
- 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 the
createAliasoptions are selected under the User Profile property. 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 AM 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 property in the user profile.
This functionality is deprecated.
- Alias Search Attribute Name
After a user is successfully authenticated, the user's profile is retrieved. AM first searches for the user based on the data store settings. If that fails to find the user, AM will use the attributes listed here to look up the user profile. This setting accepts any data store specific attribute name.
Alias Search Attribute Nameproperty is empty, AM uses the
iplanet-am-auth-user-naming-attrproperty from the
iplanet-am-auth-user-naming-attrproperty is only configurable through the ssoadm command-line tool and not through the AM console.
ssoadm get-realm-svc-attrs \ --adminid amadmin \ --password-file PATH_TO_PWDFILE \ --realm REALM \ --servicename iPlanetAMAuthService$
ssoadm set-realm-svc-attrs \ --adminid amadmin \ --password-file PATH_TO_PWDFILE \ --realm REALM \ --servicename iPlanetAMAuthService \ --attributevalues iplanet-am-auth-user-naming-attr=SEARCH_ATTRIBUTE
The following properties are available under the Account Lockout tab:
- Login Failure Lockout Mode
When enabled, AM deactivates the LDAP attribute defined in the Lockout Attribute Name property in the user's profile upon login failure. This attribute works in conjunction with the other account lockout and notification attributes.
- 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.
- 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 by the Login Failure Lockout Count property. If an attempt within the defined lockout interval time proves successful before the number of attempts reaches the number defined by the Login Failure Lockout Count property, the lockout count is reset.
- Email Address to Send Lockout Notification
Specifies one or more email addresses to which notification is sent if a user lockout occurs.
Separate multiple addresses with spaces, and append
|locale|charsetto addresses for recipients in non-English locales.
- Warn User After N Failures
Specifies the number of authentication failures after which AM displays a warning message that the user will be locked out.
- 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.
- 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. After 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.
- Lockout Attribute Name
Defines the LDAP attribute used for physical lockout. The default attribute is
inetuserstatus, although the field in the AM console is empty. The Lockout Attribute Value field must also contain an appropriate value.
- 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 AM console is empty. The Lockout Attribute Name field must also contain an appropriate value.
- Invalid Attempts Data Attribute Name
Specifies the LDAP attribute used to hold the number of failed authentication attempts towards Login Failure Lockout Count. Although the field appears empty in the AM console, AM stores this data in the
sunAMAuthInvalidAttemptsDataAttrNameattribute defined in the
sunAMAuthAccountLockoutobjectclass by default.
- Store Invalid Attempts in Data Store
When enabled, AM stores the information regarding failed authentication attempts as the value of the Invalid Attempts Data Attribute Name in the user data store. 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 AM.
Enable this property to track invalid log in attempts when using CTS-based or client-based authentication sessions.
The following properties are available under the General tab:
- Default Authentication Locale
Specifies the default language subtype to be used by the Authentication Service. The default value is
- Identity Types
Lists the type or types of identities used during a profile lookup. You can choose more than one to search on multiple types if you would like AM to conduct a second lookup if the first lookup fails. The possible values are:
Searches for identities under your agents.
Searches for identities according to your established agent group.
Searches for identities only under your agents.
Searches for identities according to your established groups.
Searches for identities according to your users.
- 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.AMAuthCallBackinterface. AM supports account lockout and password changes. AM supports password changes through the LDAP authentication module, and so the feature is only available for the LDAP module.
.jarfile containing the user status event class belongs in the
WEB-INF/libdirectory of the deployed AM instance. If you do not build a
.jarfile, add the class files under
- Use Client-Based Sessions
When enabled, AM assigns client-based sessions to users authenticating to this realm. Otherwise, AM users authenticating to this realm are assigned CTS-based sessions.
For more information about sessions, see Introducing Sessions.
- Two Factor Authentication Mandatory
When enabled, users authenticating to a chain that includes a ForgeRock Authenticator (OATH) module are always required to perform authentication using a registered device before they can access AM. When not selected, users can opt to forego registering a device and providing a token and still successfully authenticate.
Letting users choose not to provide a verification token while authenticating carries implications beyond the
sufficientflag settings on the ForgeRock Authenticator (OATH) module in the authentication chain. For example, suppose you configured authentication as follows:
The ForgeRock Authenticator (OATH) module is in an authentication chain.
The ForgeRock Authenticator (OATH) module has the
Two Factor Authentication Mandatory is not selected.
Users authenticating to the chain can authenticate successfully without providing tokens from their devices. The reason for successful authentication in this case is that the
requiredsetting relates to the execution of the ForgeRock Authenticator (OATH) module itself. Internally, the ForgeRock Authenticator (OATH) module has the ability to forego processing a token while still returning a passing status to the authentication chain.
Two Factor Authentication Mandatoryproperty only applies to modules within authentication chains, and does not affect nodes within authentication trees.
- External Login Page URL
Specifies the URL of the external login user interface, if the authentication user interface is hosted separately from AM.
When set, AM will use the provided URL as the base of the resume URI, rather than using the Base URL Source Service to obtain the base URL. AM will use this URL when constructing the resume URI if authentication is suspended in an authentication tree.
For more information about the Base URL Source Service, see "Configuring the Base URL Source Service".
- Default Authentication Level
Specifies the default authentication level for authentication modules.
The following properties are available under the Security tab:
- Module Based Authentication
When enabled, users can authenticate using module-based authentication. Otherwise, all attempts at authentication using the
module=module-namelogin parameter result in failure.
ForgeRock recommends disabling module-based authentication in production environments.
- Persistent Cookie Encryption Certificate Alias
Specifies the key pair alias in the AM keystore to use for encrypting persistent cookies.
- Zero Page Login
When enabled, AM allows users to authenticate using only GET request parameters without showing a login screen.
Enable with caution as browsers can cache credentials and servers can log credentials when they are part of the URL.
AM always allows HTTP POST requests for zero page login.
Default: false (disabled)
- Zero Page Login Referer Whitelist
Lists the HTTP referer URLs for which AM allows zero page login. These URLs are supplied in the
RefererHTTP request header, allowing clients to specify the web page that provided the link to the requested resource.
When zero page login is enabled, including the URLs for the pages from which to allow zero page login will provide some mitigation against Login Cross-Site Request Forgery (CSRF) attacks. Leave this list blank to allow zero page login from any Referer.
This setting applies for both HTTP GET and also HTTP POST requests for zero page login.
- Zero Page Login Allowed Without Referer?
When enabled, allows zero page login for requests without an HTTP
Refererrequest header. Zero page login must also be enabled.
Enabling this setting reduces the risk of login CSRF attacks with zero page login enabled, but may potentially deny legitimate requests.
- Organization Authentication Signing Secret
Specifies a cryptographically-secure random-generated HMAC shared secret for signing RESTful authentication requests. When users attempt to authenticate to the UI, AM signs a JSON Web Token (JWT) containing this shared secret. The JWT contains the authentication session ID, realm, and authentication index type value, but does not contain the user's credentials.
When modifying this value, ensure the new shared secret is Base-64 encoded and at least 128 bits in length.
The following properties are available under the Post Authentication Processing tab:
- 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|URLalthough 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.
- 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|URLalthough 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.
- 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
.jarfile containing the post processing class belongs in the
WEB-INF/libdirectory of the deployed AM instance. If you do not build a
.jarfile, add the class files under
WEB-INF/classes. For deployment, add the
.jarfile or classes into a custom AM
For information on creating post-authentication plugins, see "Creating Post-Authentication Plugins for Chains".
- 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 IDs are generated by the class specified in the Pluggable User Name Generator Class property.
- 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
- 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 SSO token. 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.protectedprefix to ensure that they cannot be edited by the client applications.
For example, if you define the user profile attribute 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
Properties that are set in the user session using User Attribute Mapping to Session Attributes cannot be modified (for example,
SSOToken.setProperty(String, String)). This results in an
SSOException. Multivalued attributes, such as
memberOf, are listed as a single session variable with a
When configuring authentication for a realm configured for client-based sessions, be careful not to add so many session attributes that the session cookie size exceeds the maximum allowable cookie size. For more information about client-based session cookies, see Session Cookies and Session Security.