chap-auth-services.xml revision 9470f6b5e11719100cdb2fef604888d5ca4fd384
<?xml version="1.0" encoding="UTF-8"?>
<!--
! CCPL HEADER START
!
! This work is licensed under the Creative Commons
! Attribution-NonCommercial-NoDerivs 3.0 Unported License.
! To view a copy of this license, visit
! http://creativecommons.org/licenses/by-nc-nd/3.0/
! or send a letter to Creative Commons, 444 Castro Street,
! Suite 900, Mountain View, California, 94041, USA.
!
! You can also obtain a copy of the license at
! src/main/resources/legal-notices/CC-BY-NC-ND.txt.
! See the License for the specific language governing permissions
! and limitations under the License.
!
! If applicable, add the following below this CCPL HEADER, with the fields
! enclosed by brackets "[]" replaced with your own identifying information:
! Portions Copyright [yyyy] [name of copyright owner]
!
! CCPL HEADER END
!
! Copyright 2011-2013 ForgeRock, Inc.
!
-->
<chapter xml:id='chap-auth-services'
xmlns='http://docbook.org/ns/docbook'
version='5.0' xml:lang='en'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation='http://docbook.org/ns/docbook http://docbook.org/xml/5.0/xsd/docbook.xsd'
xmlns:xlink='http://www.w3.org/1999/xlink'
xmlns:xinclude='http://www.w3.org/2001/XInclude'>
<title>Defining Authentication Services</title>
<para>An <firstterm>authentication</firstterm> service confirms the identity
of a user or a client application.</para>
<para>This chapter describes how to configure authentication in OpenAM.</para>
<section xml:id="what-is-authn">
<title>About Authentication in OpenAM</title>
<indexterm><primary>Authentication</primary></indexterm>
<para>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.</para>
<para>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.</para>
<para>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. <firstterm>Authentication</firstterm> is the term meaning
the determination of who a user is. This chapter covers how to set up the
authentication process. <firstterm>Authorization</firstterm> is the term
meaning determination whether a user has access to a protected resource.
Authorization is covered later.</para>
<para>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. </para>
<indexterm>
<primary>Authentication</primary>
<secondary>Modules</secondary>
</indexterm>
<indexterm>
<primary>Authentication</primary>
<secondary>Chains</secondary>
</indexterm>
<para>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 <firstterm>authentication
modules</firstterm> 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 <firstterm>authentication chaining</firstterm>.
When you chain authentication modules, you can configure each module as
required, optional, requisite, or sufficient.<footnote><para>The four terms,
required, optional, requisite, and sufficient, come from JAAS, the Java
standard for authentication and authorization.</para></footnote></para>
<itemizedlist>
<listitem>
<para>When a <firstterm>required</firstterm> module fails, the rest of
the chain is processed, but the authentication fails.</para>
<para>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.</para>
</listitem>
<listitem>
<para>When an <firstterm>optional</firstterm> module fails,
authentication continues.</para>
<para>An optional module might be used to permit a higher level of access
if the user can present a X.509 certificate for example.</para>
</listitem>
<listitem>
<para>When a <firstterm>requisite</firstterm> module fails, authentication
fails and authentication processing stops.</para>
<para>A requisite module might be used with exclusive SSO.</para>
</listitem>
<listitem>
<para>When a <firstterm>sufficient</firstterm> succeeds, authentication
is successful and later modules in the chain are skipped.</para>
<para>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.</para>
</listitem>
</itemizedlist>
<indexterm>
<primary>Authentication</primary>
<secondary>Levels</secondary>
</indexterm>
<para>With OpenAM, you can further set <firstterm>authentication
levels</firstterm> 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 <firstterm>realms</firstterm> to organize
which authentication process applies for different applications or different
domains, perhaps managed by different people.</para>
<para>When a user successfully authenticates, OpenAM creates a session, which
allows OpenAM to manage that user's access to resources. In some deployments
you need to limit how many active sessions a user can have at a given time.
For example, you might want to prevent a user from using more than two devices
at once. See <xref linkend="configure-session-quotas" /> for
instructions.</para>
<para>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.</para>
</section>
<section xml:id="configure-authn-modules">
<title>Configuring Authentication Modules</title>
<para>The OpenAM console provides two places where the OpenAM administrator
can configure authentication modules.</para>
<orderedlist>
<listitem>
<para>Under Configuration &gt; Authentication, you configure available
modules for use throughout OpenAM. What you set up here is inherited
for use elsewhere.</para>
</listitem>
<listitem>
<para>Under Access Control &gt; <replaceable>Realm Name</replaceable> &gt;
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.</para>
</listitem>
</orderedlist>
<para>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 OTP authentication requires information
about the password length and the mail server or SMS gateway for sending the
password during authentication.</para>
<section xml:id="ad-module-conf-hints">
<title>Hints For the Active Directory Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Active Directory</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthADService</literal></para>
<variablelist>
<varlistentry>
<term>Primary Active Directory Server</term>
<term>Secondary Active Directory Server</term>
<listitem>
<para>The default port for LDAP is 389. If you are connecting to
Active Directory over SSL, the default port for LDAP/SSL is 636.</para>
<para>To allow users to change passwords through OpenAM, Active Directory
requires that you connect over SSL.</para>
<para>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.</para>
<para>OpenAM first attempts to contact primary servers. If no primary
server is available, then OpenAM attempts to contact secondaries.</para>
<para>When authenticating users from a directory server that is remote
from OpenAM, set both the primary and secondary server values.</para>
<para><command>ssoadm</command> attributes: primary is
<literal>iplanet-am-auth-ldap-server</literal>; secondary is
<literal>iplanet-am-auth-ldap-server2</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>DN to Start User Search</term>
<listitem>
<para>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
<literal>OU=sales,DC=example,DC=com</literal>.</para>
<para>If multiple entries exist with identical search attribute values,
make this value specific enough to return only one entry.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-base-dn</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Bind User DN, Bind User Password</term>
<listitem>
<para>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.</para>
<para>The default is <literal>amldapuser</literal>. If the administrator
authentication chain (default: <literal>ldapService</literal>) 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
<literal>uid=amAdmin,ou=People,<replaceable>OpenAM-deploy-base</replaceable></literal>,
where <replaceable>OpenAM-deploy-base</replaceable> was set during
OpenAM configuration.</para>
<para><command>ssoadm</command> attributes:
<literal>iplanet-am-auth-ldap-bind-dn</literal> and
<literal>iplanet-am-auth-ldap-bind-passwd</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Attributes Used to Search for a User to be Authenticated</term>
<term>User Search Filter</term>
<term>Search Scope</term>
<listitem>
<para>LDAP searches for user entries return entries with attribute
values matching the filter you provide. For example if you search under
<literal>CN=Users,DC=example,DC=com</literal> with a filter
<literal>"(MAIL=bjensen@example.com)"</literal>, then the directory
returns the entry that has <literal>MAIL=bjensen@example.com</literal>.
In this example the attribute used to search for a user is
<literal>mail</literal>. Multiple attribute values mean the user can
authenticate with any one of the values. For example, if you have
both <literal>uid</literal> and <literal>mail</literal>, then Barbara
Jensen can authenticate with either <literal>bjensen</literal> or
<literal>bjensen@example.com</literal>.</para>
<para>The User Search Filter text box provides a more complex filter. For example,
if you search on <literal>mail</literal> and add User Search Filter
<literal>(objectClass=inetOrgPerson)</literal>, then OpenAM uses the resulting
search filter <literal>(&amp;(mail=<replaceable>address</replaceable>)
(objectClass=inetOrgPerson))</literal>, where <replaceable>address</replaceable>
is the mail address provided by the user.</para>
<para>This controls how and the level of the directory that will be searched.
You can set the search to run at a high level or against a specific area.</para>
<itemizedlist>
<listitem>
<para>OBJECT will search only for the entry specified as the DN to Start User
Search.</para>
</listitem>
<listitem>
<para>ONELEVEL will search only the entries that are directly children of that
object.</para>
</listitem>
<listitem>
<para>SUBTREE will search the entry specified and every entry under it.</para>
</listitem>
</itemizedlist>
<para><command>ssoadm</command> attributes:
<literal>iplanet-am-auth-ldap-user-naming-attribute</literal>,
<literal>iplanet-am-auth-ldap-user-search-attributes</literal>,
<literal>iplanet-am-auth-ldap-search-filter</literal>, and
<literal>iplanet-am-auth-ldap-search-scope</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SSL/TLS Access to Active Directory Server</term>
<listitem>
<para>If you enable SSL/TLS, 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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-ssl-enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Return User DN to DataStore</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-return-user-dn</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Active Directory Server Check Interval</term>
<listitem>
<para>Used by the failover mechanism. Specifies the number of minutes
between checks whether a previously unavailable Active Directory has
become available again.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-server-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User Creation Attributes</term>
<listitem>
<para>This list lets you map (external) attribute names from Active
Directory to (internal) attribute names used by OpenAM.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-ldap-user-creation-attr-list</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthADAuthLevel</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="adaptive-auth-module-conf-hints">
<title>Hints For the Adaptive Risk Authentication Module</title>
<para>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.</para>
<mediaobject xml:id="figure-adaptive-auth-module">
<alt>Including the Adaptive Risk module in an authentication chain</alt>
<imageobject>
<imagedata fileref="images/adaptive-auth-module.png" format="PNG" />
</imageobject>
<textobject><para>With the Adaptive Risk module as sufficient, OpenAM
continues to the next module in the chain should the Adaptive Risk module
return failure.</para></textobject>
</mediaobject>
<para>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.</para>
<para>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
<literal>org.forgerock.openam.authentication.modules.adaptive.Adaptive</literal>
to the list of post authentication plugins.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Adaptive risk</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthAdaptiveService</literal></para>
<variablelist>
<title>General</title>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-auth-level</literal></para></listitem>
</varlistentry>
<varlistentry>
<term>Risk Threshold</term>
<listitem>
<para>Risk threshold score. If the sum of the Scores is greater than the
threshold, the Adaptive Risk module returns failure. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-auth-threshold</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Failed Authentications</title>
<varlistentry>
<term>Failed Authentication Check</term>
<listitem>
<para>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).</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-failure-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the Failed
Authentication Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-failure-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the Failed Authentication Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-failure-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>IP Address Range</title>
<varlistentry>
<term>IP Range Check</term>
<listitem>
<para>When enabled, check whether the client IP address is within one
of the specified IP Ranges.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-range-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>IP Range</term>
<listitem>
<para>For IPv4, specifies a list of IP ranges either in CIDR-style notation
(<literal><replaceable>x.x.x.x</replaceable>/<replaceable>YY</replaceable></literal>)
or as a range from one address to another
(<literal><replaceable>x.x.x.x</replaceable>-<replaceable>y.y.y.y</replaceable></literal>,
meaning from <replaceable>x.x.x.x</replaceable> to
<replaceable>y.y.y.y</replaceable>).</para>
<para>For IPv6, specifies a list of IP ranges either in CIDR-style notation
(<literal><replaceable>X:X:X:X:X:X:X:X</replaceable>/<replaceable>YY</replaceable></literal>)
or as a range from one address to another
(<literal><replaceable>X:X:X:X:X:X:X:X</replaceable>-<replaceable>Y:Y:Y:Y:Y:Y:Y:Y</replaceable></literal>,
meaning from <replaceable>X:X:X:X:X:X:X:X</replaceable> to
<replaceable>Y:Y:Y:Y:Y:Y:Y:Y</replaceable>).</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-range-range</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the IP Range
Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-range-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the IP Range Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-range-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>IP Address History</title>
<varlistentry>
<term>IP History Check</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-history-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>History Size</term>
<listitem>
<para>Specifies how many IP address values to retain on the profile
attribute you specify. Default: 5</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-ip-adaptive-history-count</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Profile Attribute Name</term>
<listitem>
<para>Name of the user profile attribute on which to store known IP
addresses. Default: <literal>iphistory</literal></para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-history-attribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Save Successful IP Address</term>
<listitem>
<para>When enabled, save new client IP addresses to the known IP address
list following successful authentication.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-history-save</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the IP History
Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-history-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the IP History Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-ip-history-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Known Cookie</title>
<varlistentry>
<term>Cookie Value Check</term>
<listitem>
<para>When enabled, check whether the client browser request has the
specified cookie and optional cookie value.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-known-cookie-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Cookie Name</term>
<listitem>
<para>Specifies the name of the cookie for which OpenAM checks when
you enable the Cookie Value Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-known-cookie-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Cookie Value</term>
<listitem>
<para>Specifies the value of the cookie for which OpenAM checks. If
no value is specified, OpenAM does not check the cookie value.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-known-cookie-value</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Save Cookie Value on Successful Login</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-known-cookie-save</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if user passes the Cookie Value
Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-known-cookie-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the Cookie Value Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-known-cookie-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Device Cookie</title>
<varlistentry>
<term>Device Registration Cookie Check</term>
<listitem>
<para>When enabled, check whether the client browser request has the
specified cookie with the correct device registration identifier as
the value.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-device-cookie-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Cookie Name</term>
<listitem>
<para>Specifies the name of the cookie for the Device Registration Cookie
Check. Default: Device</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-device-cookie-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Save Device Registration on Successful Login</term>
<listitem>
<para>When enabled, save the specified cookie with a hashed device
identifier value in the client's browser following successful
authentication.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-device-cookie-save</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the Device
Registration Cookie Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-device-cookie-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the Device Registration Cookie Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-device-cookie-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Time Since Last Login</title>
<varlistentry>
<term>Time Since Last Login Check</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-time-since-last-login-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Cookie Name</term>
<listitem>
<para>Specifies the name of the cookie holding the encrypted last login
time value.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-time-since-last-login-cookie-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Max Time since Last Login</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-time-since-last-login-value</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Save time of Successful Login</term>
<listitem>
<para>When enabled, save the specified cookie with the current time
encrypted as the last login value in the client's browser following
successful authentication.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-time-since-last-login-save</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the Time Since
Last Login Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-time-since-last-login-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the Time Since Last Login Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-time-since-last-login-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Profile Attribute</title>
<varlistentry>
<term>Profile Risk Attribute check</term>
<listitem>
<para>When enabled, check whether the user profile contains the specified
attribute and value.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-risk-attribute-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Attribute Name</term>
<listitem>
<para>Specifies the attribute to check on the user profile for the
specified value.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-risk-attribute-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Attribute Value</term>
<listitem>
<para>Specifies the value to match on the profile attribute. If the
attribute is multi-valued, a single match is sufficient to pass the
check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-risk-attribute-value</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the Profile Risk
Attribute Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-risk-attribute-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the Profile Risk Attribute Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-risk-attribute-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Geo Location</title>
<varlistentry>
<term>Geolocation Country Code Check</term>
<listitem>
<para>When enabled, check whether the client IP address location matches
a country specified in the Valid Country Codes list. The </para>
<para><command>ssoadm</command> attribute:
<literal>forgerock-am-auth-adaptive-geo-location-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Geolocation Database location</term>
<listitem>
<para>Path to GeoIP data file used to convert IP addresses to
country locations. The geolocation database is not packaged with OpenAM.
You can downloaded the GeoIP Country database from <link
xlink:href="http://www.maxmind.com/en/country">MaxMind</link>. Use the binary
.dat file format, rather than .csv. You can use the GeoLite Country database
for testing.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-geo-location-database</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Valid Country Codes</term>
<listitem>
<para>Specifies the list of country codes to match. Use
<literal>|</literal> to separate multiple values.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-geo-location-values</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the Geolocation
Country Code Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-geo-location-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the Geolocation Country Code Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-geo-location-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Request Header</title>
<varlistentry>
<term>Request Header Check</term>
<listitem>
<para>When enabled, check whether the client browser request has the
specified header with the correct value.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-req-header-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Request Header Name</term>
<listitem>
<para>Specifies the name of the request header for the Request Header
Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-req-header-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Request Header Value</term>
<listitem>
<para>Specifies the value of the request header for the Request Header
Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-req-header-value</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Score</term>
<listitem>
<para>Value to add to the total score if the user fails the Request
Header Check. Default: 1</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-req-header-score</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invert Result</term>
<listitem>
<para>When selected, add the Score to the total score if the user
passes the Request Header Check.</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-adaptive-req-header-invert</literal></para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="anon-module-conf-hints">
<title>Hints For the Anonymous Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Anonymous</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthAnonymousService</literal></para>
<variablelist>
<varlistentry>
<term>Valid Anonymous Users</term>
<listitem>
<para>Specifies valid anonymous user IDs in addition to the default.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-anonymous-users-list</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Default Anonymous User Name</term>
<listitem>
<para>Specifies the user ID assigned by the module if the Valid
Anonymous Users list is empty. Default: <literal>anonymous</literal></para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-anonymous-default-user-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Case Sensitive User IDs</term>
<listitem>
<para>Whether case matters for anonymous user IDs.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-anonymous-case-sensitive</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-anonymous-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="cert-module-conf-hints">
<title>Hints For the Certificate Authentication Module</title>
<para>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 Certificate 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.</para>
<para>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.</para>
<para>Access to the LDAP server and how to search for users is similar
to LDAP module configuration as in <xref linkend="ldap-module-conf-hints" />.
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 <literal>C=FR, O=Example Corp, CN=Barbara
Jensen</literal>, and Barbara Jensen's entry in the directory has
<literal>cn=Barbara Jensen</literal>, then you can use <literal>CN=Barbara
Jensen</literal> from the Subject DN to search for the entry with
<literal>cn=Barbara Jensen</literal> in the directory.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>X509 certificate based</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthCertService</literal></para>
<variablelist>
<varlistentry>
<term>Match Certificate in LDAP</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-check-cert-in-ldap</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Subject DN Attribute Used to Search LDAP for Certificates</term>
<listitem>
<para>Indicates which attribute and value in the certificate Subject DN
is used to find the LDAP entry holding the certificate.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-attr-check-ldap</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Match Certificate to CRL</term>
<listitem>
<para>When enabled, OpenAM checks whether the certificate has been
revoked according to a CRL in the LDAP directory.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-check-crl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Issuer DN Attribute Used to Search LDAP for CRLs</term>
<listitem>
<para>Indicates which attribute and value in the certificate Issuer DN
is used to find the CRL in the LDAP directory.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-attr-check-crl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>HTTP Parameters for CRL Update</term>
<listitem>
<para>Your certificate authority should provide the URL to use here,
from which OpenAM can get CRL updates.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-param-get-crl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Match CA Certificate to CRL</term>
<listitem>
<para>When enabled, OpenAM checks the CRL against the CA certificate to
ensure it has not been compromised.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMValidateCACert</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>OCSP Validation</term>
<listitem>
<para>Enable this to use Online Certificate Status Protocol (OCSP)
instead of CRLs to check certificates' revocation status.</para>
<para>If you enable this, you also must configure OSCP for OpenAM
under Configuration &gt; Server and Sites &gt; Default Server Settings,
or Configuration &gt; Server and Sites &gt; <replaceable>Server
Name</replaceable> &gt; Security.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-check-ocsp</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Server Where Certificates are Stored</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-ldap-provider-url</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Search Start or Base DN</term>
<listitem>
<para>Valid base DN for the LDAP search, such as
<literal>dc=example,dc=com</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-start-search-loc</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Server Authentication User, LDAP Server Authentication Password</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attributes:
<literal>iplanet-am-auth-cert-principal-user</literal>, and
<literal> iplanet-am-auth-cert-principal-passwd</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Use SSL/TLS for LDAP Access</term>
<listitem>
<para>If you use SSL/TLS for LDAP access, OpenAM must be able to trust the
LDAP server certificate.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-use-ssl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Certificate Field Used to Access User Profile</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-user-profile-mapper</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Other Certificate Field Used to Access User Profile</term>
<listitem>
<para>This field is only used if the Certificate Field Used to Access
User Profile attribute is set to other. This field allows a custom
certificate field to be used as the basis of the user search.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-user-profile-mapper-other</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SubjectAltNameExt Value Type to Access User Profile</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal> iplanet-am-auth-cert-user-profile-mapper-ext</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Trusted Remote Hosts</term>
<listitem>
<para>Hosts trusted to send certificates to OpenAM, such as load balancers
doing SSL termination, or OpenAM distributed authentication UI
instances.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-gw-cert-auth-enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>HTTP Header Name for Client Certificate</term>
<listitem>
<para>If you configure trusted hosts, specify the HTTP header name for
the client certificate inserted by the trusted host.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMHttpParamName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-cert-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="core-module-conf-hints">
<title>Hints For the Core Authentication Module</title>
<para>The Core module is a sort of meta-module.</para>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Core</secondary>
</indexterm>
<itemizedlist>
<para>The Core Authentication module has two configurable screens:</para>
<listitem>
<para><xref linkend="auth-core-main-page" /></para>
</listitem>
<listitem>
<para><xref linkend="auth-all-core" /></para>
</listitem>
</itemizedlist>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthService</literal></para>
<variablelist xml:id="auth-core-main-page">
<title>Core - Authentication Main Page</title>
<para>This section of the Core Authentication module is on the main authentication
page before the Module Instances Table.</para>
<varlistentry>
<term>Organization Authentication Configuration</term>
<listitem>
<para>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. Default: ldapService</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-org-config</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Administrator Authentication Configuration</term>
<listitem>
<para>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.
Default: ldapService</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-admin-auth-module</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Organization Authentication Keystore Alias</term>
<listitem>
<para>Defines the alias for public and private keys used in the Keystore for
RESTful authentication. Default: test</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-key-alias</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Default Success Login URL</term>
<listitem>
<para>Accepts a list of values that specifies where users are directed
after successful authentication. The format of this attribute is
<literal><replaceable>client-type</replaceable>|<replaceable>URL</replaceable></literal>
although the only value you can specify at this time is a URL
which assumes the type HTML. The default value is
<literal>/openam/console</literal>. Values that do not specify HTTP have
that appended to the deployment URI.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-login-success-url</literal></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist xml:id="auth-all-core">
<title>Core - All Core Settings Page</title>
<varlistentry>
<term><emphasis>User Profile</emphasis></term>
<term>User Profile</term>
<listitem>
<para>Whether a user profile needs to exist in the user data store,
or should be created on successful authentication.</para>
<variablelist>
<varlistentry>
<term>Dynamic</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Dynamic with User Alias</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Ignored</term>
<listitem>
<para>Specifies that a user profile is not required for the
Authentication Service to issue an SSOToken after a successful
authentication.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Required</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
</variablelist>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-dynamic-profile-creation</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User Profile Dynamic Creation Default Roles</term>
<listitem>
<para>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.</para>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-default-role</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Alias Search Attribute Name</term>
<listitem>
<para>After a user is successfully authenticated, the user's profile is
retrieved. OpenAM first searches for the user based on the data store settings.
If that fails to find the user, OpenAM will use the attributes listed here to
lookup the user profile. This setting accepts any data store specific attribute
name.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-alias-attr-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>Persistent Cookie</emphasis></term>
<term>Persistent Cookie Mode</term>
<listitem>
<para>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).</para>
<para>The client must explicitly request a persistent cookie by adding
<literal>iPSPCookie=yes</literal> as a parameter to the login URL. OpenAM
sets a <literal>DProPCookie</literal> as described in
<xref linkend="authn-from-browser" />.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-persistent-cookie-mode</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Persistent Cookie Maximum Time</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-persistent-cookie-time</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>Account Lockout</emphasis></term>
<term>Login Failure Lockout Mode</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-login-failure-lockout-mode</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Login Failure Lockout Count</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-login-failure-count</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Login Failure Lockout Interval</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-login-failure-duration</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Email Address to Send Lockout Notification</term>
<listitem>
<para>Specify one (or more) email address(es) to which notification is
sent if a user lockout occurs.</para>
<para>Separate multiple addresses with spaces, and append
<literal>|<replaceable>locale</replaceable>|<replaceable>charset</replaceable></literal>
to addresses for recipients in non-English locales.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-lockout-email-address</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Warn User After N Failures</term>
<listitem>
<para>The number of authentication failures after which OpenAM displays
a warning message that the user will be locked out.</para>
<para><command>ssoadm</command> attribute:
<literal> iplanet-am-auth-lockout-warn-user</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Login Failure Lockout Duration</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-lockout-duration</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Lockout Duration Multiplier</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>sunLockoutDurationMultiplier</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Lockout Attribute Name</term>
<listitem>
<para>Defines the LDAP attribute used for physical lockout. The default
value is <literal>inetuserstatus</literal>, although the field in the
OpenAM console is empty. The Lockout Attribute Value field must also
contain an appropriate value.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-lockout-attribute-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Lockout Attribute Value</term>
<listitem>
<para>Specifies the action to take on the attribute defined in Lockout
Attribute Name. The default value is <literal>inactive</literal>,
although the field in the OpenAM console is empty. The Lockout Attribute
Name field must also contain an appropriate value.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-lockout-attribute-value</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Invalid Attempts Data Attribute Name</term>
<listitem>
<para>Specifies the LDAP attribute used to hold the number of failed
authentication attempts towards Login Failure Lockout Count.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthInvalidAttemptsDataAttrName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Store Invalid Attempts in Data Store</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>sunStoreInvalidAttemptsInDS</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>General</emphasis></term>
<term>Default Authentication Locale</term>
<listitem>
<para>Specifies the default language subtype to be used by the
Authentication Service. The default value is
<literal>en_US</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-locale</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Identity Types</term>
<listitem>
<para>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 OpenAM to
conduct a second lookup if the first lookup fails. Default: Agent and User</para>
<variablelist>
<varlistentry>
<term>Agent</term>
<listitem>
<para>Searches for identities under your agents.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>agentgroup</term>
<listitem>
<para>Searches for identities according to your established agent group.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>agentonly</term>
<listitem>
<para>Searches for identities only under your agents.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Group</term>
<listitem>
<para>Searches for identities according to your established groups.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>User</term>
<listitem>
<para>Searches for identities according to your users.</para>
</listitem>
</varlistentry>
</variablelist>
<para><command>ssoadm</command> attribute:
<literal>sunAMIdentityType</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Pluggable User Status Event Classes</term>
<listitem>
<para>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
<literal>com.sun.identity.authentication.spi.AMAuthCallBack</literal>
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.</para>
<para>A .jar containing the user status event class belongs in
the <filename>WEB-INF/lib</filename> directory of the deployed OpenAM
instance. If you do not build a .jar, add the class files under
<filename>WEB-INF/classes</filename>. <!--For deployment, add the .jar or
classes into a custom OpenAM .war file.--></para>
<para><command>ssoadm</command> attribute:
<literal>sunAMUserStatusCallbackPlugins</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Default Authentication Level</term>
<listitem>
<para>Specifies the default authentication level for authentication modules.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-default-auth-level</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>Security</emphasis></term>
<term>Module Based Authentication</term>
<listitem>
<para>Enables users to authenticate using module-based authentication.
Otherwise, all attempts at authentication using the
<literal>module=<replaceable>module-name</replaceable></literal> login
parameter result in failure. It is recommended that this be turned off in
a production environment.</para>
<para><command>ssoadm</command> attribute:
<literal>sunEnableModuleBasedAuth</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Valid goto URL domains</term>
<listitem>
<para>List external domains to which clients can be redirected after
authentication. This attribute requires valid DNS domains that reflect
the set policy rules, such as https://website.example.com/* or
https://website.example.com/*?*.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-valid-goto-domains</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Zero Page Login</term>
<listitem>
<para>Enables the administrator to allow users to authenticate to a single
authentication screen using GET request parameters. Enable this with
caution as it can allow credentials to be cached.</para>
<para><command>ssoadm</command> attribute:
<literal>openam.auth.zero.page.login.enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>Post Authentication Processing</emphasis></term>
<term>Default Success Login URL</term>
<listitem>
<para>Accepts a list of values that specifies where users are directed
after successful authentication. The format of this attribute is
<literal><replaceable>client-type</replaceable>|<replaceable>URL</replaceable></literal>
although the only value you can specify at this time is a URL
which assumes the type HTML. The default value is
<literal>/openam/console</literal>. Values that do not specify HTTP have
that appended to the deployment URI.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-login-success-url</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Default Failure Login URL</term>
<listitem>
<para>Accepts a list of values that specifies where users are directed
after authentication has failed. The format of this attribute is
<literal><replaceable>client-type</replaceable>|<replaceable>URL</replaceable></literal>
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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-login-failure-url</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Post Processing Classes</term>
<listitem>
<para>Specifies one or more Java classes used to customize post
authentication processes for successful or unsuccessful logins.
The Java class must implement the
<literal>com.sun.identity.authentication.spi.AMPostAuthProcessInterface</literal>
OpenAM interface.</para>
<para>A .jar containing the post processing class belongs in
the <filename>WEB-INF/lib</filename> directory of the deployed OpenAM
instance. If you do not build a .jar, add the class files under
<filename>WEB-INF/classes</filename>. For deployment, add the .jar or
classes into a custom OpenAM .war file.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-post-login-process-class</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Generate UserID Mode</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-username-generator-enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Pluggable User Name Generator Class</term>
<listitem>
<para>Specifies the name of the class used to generate alternate user
identifiers when Generate UserID Mode is enabled. The default value is
<literal>com.sun.identity.authentication.spi.DefaultUserIDGenerator</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-username-generator-class</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User Attribute Mapping to Session Attribute</term>
<listitem>
<para>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
<literal><replaceable>User-Profile-Attribute</replaceable>|<replaceable>Session-Attribute-Name</replaceable></literal>.
If <replaceable>Session-Attribute-Name</replaceable> is not specified,
the value of <replaceable>User-Profile-Attribute</replaceable> is used.
All session attributes contain the <literal>am.protected</literal> prefix
to ensure that they cannot be edited by the Client SDK.</para>
<para>For example, if you define the user profile attribute as mail and
the user's email address (available in the user session) as
<literal>user.mail</literal>, the entry for this attribute would be
<literal>mail|user.mail</literal>. After a successful authentication,
the <literal>SSOToken.getProperty(String)</literal> 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
<literal>SSOToken.getProperty("am.protected.user.mail")</literal> method
call.</para>
<para>Properties that are set in the user session using User Attribute
Mapping to Session Attributes can not be modified (for example,
<literal>SSOToken.setProperty(String, String)</literal>). This results in
an <literal>SSOException</literal>. Multi-value attributes, such as
<literal>memberOf</literal>, are listed as a single session variable
with a <literal>|</literal> separator.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMUserAttributesSessionMapping</literal></para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="datastore-module-conf-hints">
<title>Hints For the Data Store Authentication Module</title>
<para>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.</para>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Data Store</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthDataStoreService</literal></para>
<variablelist>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthDataStoreAuthLevel</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="device-print-auth-module-conf-hints">
<title>Hints For the Device Print Authentication Module</title>
<para>The Device Print module is a device fingerprinter. It supports the risk-based identification
of the variety of devices used to connect to SPs. This module does not stand on its own, as it
uses authentication information from a service to validate a username. The Device Print module then
validates other characteristics of the user's system.</para>
<note><para>The following example
assumes that the Device Print module comes after LDAP authentication. Alternatively, you could
set it up after another directory service module such as Active Directory, Data Store, RADIUS, or
Windows NT.</para></note>
<indexterm>
<primary>Device</primary>
<secondary>Fingerprinting</secondary>
</indexterm>
<mediaobject xml:id="figure-device-print-module">
<alt>Including the Device Print module in an authentication chain</alt>
<imageobject>
<imagedata fileref="images/device-print-module.png" format="PNG" />
</imageobject>
<textobject><para>The Device Print module must come after another module that validates the associated
username. Appropriate modules include Active Directory, Data Store, LDAP, RADIUS, and Windows NT.
</para></textobject>
</mediaobject>
<para>A device fingerprint is based on the unique characteristics of a user like yourself and your
associated device. You can configure the characteristics that should be part of the fingerprint.
These characteristics can include:</para>
<itemizedlist>
<listitem>
<para>User agents, associated with the configuration of a web browser.</para>
</listitem>
<listitem>
<para>Installed fonts.</para>
</listitem>
<listitem>
<para>The plugins installed for the web browser.</para>
</listitem>
<listitem>
<para>The resolution and color depth associated with a display</para>
</listitem>
<listitem>
<para>The timezone or even the geolocation of a device.</para>
</listitem>
</itemizedlist>
<para>You can specify <literal>penalty points</literal> when characteristics of the fingerprint have
changed. If the total <literal>penalty points</literal> exceeds some configured score, the user may
be asked to verify their identity using HOTP.</para>
<para>The default value for each <literal>*-penalty-points</literal>
attribute is 35, with a <literal>*-max-tolerated-penalty-points</literal> of 50.
In other words, if more than one characteristic of the device fingerprint has changed, the
module assumes that the user is trying to connect from a different system.</para>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthDevicePrintModuleService</literal></para>
<variablelist>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPAuthLevel</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Profile expiration days</term>
<listitem>
<para>The list of device attributes is collected in a profile, which automatically expires
in a given number of days. Default: 30.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-profile-expiration-days</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Maximum stored profile quantity</term>
<listitem>
<para>The number of device profiles may be limited by user. Default: 5.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-maximum-profiles-stored-quantity</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Automatically store new profiles</term>
<listitem>
<para>When enabled, new device profiles are automatically stored, once the HOTP is verified.
Otherwise, the user is prompted for confirmation.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-store-profiles-without-confirmation</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Default user profile name</term>
<listitem>
<para>Every device requires a default profile name that represents the user.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-default-profile-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User agent penalty points</term>
<listitem>
<para>Specifies the number of penalty points added when there is a difference between the current
and stored user agent. The module adds a fixed number of points if the web browser or
related fields are changed. Version differences are ignored if the
<literal>User-Agent version ignore</literal> attribute is active. Default: 35.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-user-agent-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Installed fonts penalty points</term>
<listitem>
<para>Frequently, when a user installs a new software component, additional fonts are installed.
The Device Print module adds a fixed number of penalty points if there is a change in the
installed fonts since the last login beyond some maximum tolerated level, and the
<literal>Installed fonts required</literal> attribute is enabled. Default: 35.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-installed-fonts-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Installed plugins penalty points</term>
<listitem>
<para>Most devices have a number of plugins installed on their browsers, such as Java, Flash, and
document readers. If the plugins feature is enabled, and there is a change beyond a maximum
tolerated level, a fixed number of penalty points is added. Default: 35.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-installed-plugins-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Screen color depth penalty points</term>
<listitem>
<para>Most client devices are connected to a color monitor, or at least have settings related to
such a device. If the <literal>Screen parameters</literal>feature is enabled, and a change in
color depth is detected, a fixed number of penalty points is added. Default: 35.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-screen-color-depth-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Screen resolution penalty points</term>
<listitem>
<para>Differences in screen resolution sometimes indicate that the user has changed monitors, or
perhaps is adjusting to changing eyesight. Whenever a different screen resolution is detected,
a fixed number of penalty points is added. Default: 35.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-screen-resolution-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Timezone penalty points</term>
<listitem>
<para>Whenever a connection is made from a different timezone, the Device Print module normally
adds a fixed number of penalty points. Organizations where most users travel may want to set
this attribute to a lower value. Default: 35.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-timezone-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Allowed location range</term>
<listitem>
<para>If geolocation is enabled, each profile should include a geographic location. The allowed
location range specifies a maximum distance, in miles. If a user has travelled beyond that distance,
the <literal>Location penalty points</literal> is added to the total. Default: 100.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-location-allowed-range</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User-Agent version ignore</term>
<listitem>
<para>Upgrades change the version associated with a user agent. Unless this option is enabled, every
change in the version of a browser or related fields is detected as a difference with the stored
profile.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-ignore-version-in-user-agent</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Max number of tolerated different installed fonts</term>
<listitem>
<para>If the <literal>Installed fonts required</literal> attribute is enabled, a comparison is made
in installed fonts between the existing and stored profiles.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-max-tolerated-diffs-in-installed-fonts</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Max tolerated percentage difference between installed fonts</term>
<listitem>
<para>If the <literal>Installed fonts required</literal> attribute is enabled, a comparison is made
in installed fonts between the existing and stored profiles. Any differences in number of fonts
is noted in percent.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-max-tolerated-percentage-to-mark-as-different-installed-fonts</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Max number of tolerated different installed plugins</term>
<listitem>
<para>If the <literal>Installed plugins required</literal> attribute is enabled, a comparison is made
between the installed plugins defined in the existing and stored profiles.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-max-tolerated-diffs-in-installed-plugins</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Max tolerated percentage difference between installed plugins</term>
<listitem>
<para>If the <literal>Installed plugins required</literal> attribute is enabled, a comparison is
made between the installed plugins defined in the existing and stored profiles. Any differences
in number of plugins is noted in percent.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-max-tolerated-percentage-to-mark-as-different-plugins</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User agent required</term>
<listitem>
<para>The user agent, as defined by <link xlink:show="new"
xlink:href="http://tools.ietf.org/html/rfc4226#section-14.43">RFC 4226 Section 14.43</link>
provides information about the browser, and frequently on the operating system. Default:
enabled.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-user-agent-required</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Installed plugins required</term>
<listitem>
<para>Plugins are components that add a specific feature to an existing application. In this
context, examples of browser plugins are flash, java, and shockwave.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-plugins-required</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Installed fonts required</term>
<listitem>
<para>Fonts are frequently added to an operating system when new applications are installed. If
enabled, installed font information is stored as part of the profile, and checked upon
reconnection for comparison.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-fonts-required</literal></para>
</listitem>
</varlistentry>
<!-- see OPENAM-2492; this should be changed (IMO) to "Geolocation required" -->
<varlistentry>
<term>Geolocation required</term>
<listitem>
<para>The geographic location of a device can be tracked. Can be used to limit access from this device to a
specified range.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-geolocation-required</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Screen parameters required</term>
<listitem>
<para>Display parameters can be used to help differentiate a profile. If enabled, the Device Print module uses
screen color depth and resolution.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-screen-params-required</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Time zone required</term>
<listitem>
<para>The time zone of the current and stored profiles can be collected and compared.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-timezone-required</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Location penalty points</term>
<listitem>
<para>If geo-location has been enabled, and the current location does not match the value stored in
the profile this many points are added as a penalty. Default: 35.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-location-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Maximum tolerated penalty points</term>
<listitem>
<para>A limit, in number of points, between the current and stored Device Print profiles. If the
total is below that value, the Device Print module sees a match. Default: 50.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-adaptive-device-print-max-tolerated-penalty-points</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SMS Gateway Implementation Class</term>
<listitem>
<para>Change this if you must customize the SMS gateway implementation.
The default class sends an SMS or email, depending on the
configuration.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMSGatewayImplClassName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Host Name</term>
<listitem>
<para>Host name of the mail server supporting Simple Message Transfer
Protocol for electronic mail.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPHostName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Host Port</term>
<listitem>
<para>The default outgoing mail server port is 25, 465
(when connecting over SSL).</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPHostPort</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Authentication Username</term>
<listitem>
<para>User name for OpenAM to connect to the mail server.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPUserName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Authentication Password</term>
<listitem>
<para>Password for OpenAM to connect to the mail server.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPUserPassword</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Secure Connection</term>
<listitem>
<para>If OpenAM connects to the mail server securely, OpenAM must be able
to trust the server certificate.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPSSLEnabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Email From Address</term>
<listitem>
<para>The <literal>From:</literal> address when sending a one-time
password by mail.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPFromAddress</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>One Time Password Validity Length (in minutes)</term>
<listitem>
<para>One-time passwords are valid for 5 minutes after they are generated
by default.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPPasswordValidityDuration</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>One Time Password Length (in digits)</term>
<listitem>
<para>Set the length of the one-time password to 6 or 8 digits.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPPasswordLength</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>One Time Password Delivery</term>
<listitem>
<para>Send the one-time password by SMS, by mail, or both.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPasswordDelivery</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mobile Phone Number Attribute Names</term>
<listitem>
<para>Provides the attribute name used for the text message. The
default value is <literal>telephoneNumber</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>openamTelephoneAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mobile Carrier Attribute Name</term>
<listitem>
<para>Provides the name of the carrier that will send the text
message.</para>
<para>Every carrier has their own attribute name ending, for example Verizon
uses @vtext.com or vtext.com. Contact your mobile carrier to find out what their
attribute name is. If you will be sending international texts, ask your carrier
if a country code is a required.</para>
<para><command>ssoadm</command> attribute:
<literal>openamSMSCarrierAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Email Attribute Name</term>
<listitem>
<para>Provides the attribute name used to email the OTP. The
default value is <literal>mail</literal> (email).</para>
<para><command>ssoadm</command> attribute:
<literal>openamEmailAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Auto Send OTP Code</term>
<listitem>
<para>Setup the HOTP module to automatically generate an email
or text message when users begin the login process. </para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPAutoClicking</literal></para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="federation-module-conf-hints">
<title>Hints For the Federation Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Federation</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthFederationService</literal></para>
<variablelist>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthFederationAuthLevel</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="hotp-module-conf-hints">
<title>Hints For the HOTP Authentication Module</title>
<para>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.</para>
<para>To use HOTP you set up an authentication chain with the Data Store
module as the <literal>requisite</literal> first module, and the HOTP module
as the second <literal>requisite</literal> 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.</para>
<para>You can set the HOTP module to automatically generate a password when
users begin logging into the system. You can also setup a mobile phone,
mobile carrier, and email attributes for tighter controls over where
the messages are generated and what provider the messages go through to reach
the user.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>HMAC One-Time Password (HOTP)</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthHOTPService</literal></para>
<variablelist>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPAuthLevel</literal></para></listitem>
</varlistentry>
<varlistentry>
<term>SMS Gateway Implementation Class</term>
<listitem>
<para>Change this if you must customize the SMS gateway implementation.
The default class sends an SMS or email, depending on the
configuration.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMSGatewayImplClassName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Host Name</term>
<listitem>
<para>Host name of the mail server supporting Simple Message Transfer
Protocol for electronic mail.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPHostName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Host Port</term>
<listitem>
<para>The default outgoing mail server port is 25, 465 (when connecting over SSL).</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPHostPort</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Authentication Username</term>
<listitem>
<para>User name for OpenAM to connect to the mail server.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPUserName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Authentication Password</term>
<listitem>
<para>Password for OpenAM to connect to the mail server.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPUserPassword</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Secure Connection</term>
<listitem>
<para>If OpenAM connects to the mail server securely, OpenAM must be able
to trust the server certificate.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPSSLEnabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Email From Address</term>
<listitem>
<para>The <literal>From:</literal> address when sending a one-time
password by mail.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPSMTPFromAddress</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>One Time Password Validity Length (in minutes)</term>
<listitem>
<para>One-time passwords are valid for 5 minutes after they are generated
by default.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPPasswordValidityDuration</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>One Time Password Length (in digits)</term>
<listitem>
<para>Set the length of the one-time password to 6 or 8 digits.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPPasswordLength</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>One Time Password Delivery</term>
<listitem>
<para>Send the one-time password by SMS, by mail, or both.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPasswordDelivery</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mobile Phone Number Attribute Names</term>
<listitem>
<para>Provides the attribute name used for the text message. The
default value is <literal>telephoneNumber</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>openamTelephoneAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mobile Carrier Attribute Name</term>
<listitem>
<para>Provides the name of the carrier that will send the text
message.</para>
<para>Every carrier has their own attribute name ending, for example Verizon
uses @vtext.com or vtext.com. Contact your mobile carrier to find out what their
attribute name is. If you will be sending international texts, ask your carrier
if a country code is a required.</para>
<para><command>ssoadm</command> attribute:
<literal>openamSMSCarrierAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Email Attribute Name</term>
<listitem>
<para>Provides the attribute name used to email the OTP. The
default value is <literal>mail</literal> (email).</para>
<para><command>ssoadm</command> attribute:
<literal>openamEmailAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Auto Send OTP Code</term>
<listitem>
<para>Setup the HOTP module to automatically generate an email
or text message when users begin the login process. </para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthHOTPAutoClicking</literal></para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="http-module-conf-hints">
<title>Hints For the HTTP Basic Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>HTTP Basic</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthHTTPBasicService</literal></para>
<variablelist>
<varlistentry>
<term>Backend Module Name</term>
<listitem>
<para>Specifies the module that checks the user credentials.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-http-basic-module-configured</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-httpbasic-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="jdbc-module-conf-hints">
<title>Hints For the JDBC Authentication Module</title>
<para>The Java Database Connectivity (JDBC) module lets OpenAM connect to
a database such as MySQL or Oracle DB to authenticate users.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>JDBC</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthJDBCService</literal></para>
<variablelist>
<varlistentry>
<term>Connection Type</term>
<listitem>
<para>Choose Connection pool is retrieved via JNDI to connect using the
Java Naming and Directory Interface connection pool supported by the web
container in which OpenAM runs. Choose Non-persistent JDBC connection to
connect directly through the JDBC driver.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCConnectionType</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Connection Pool JNDI Name</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCJndiName</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>JDBC Driver</term>
<listitem>
<para>When using Non-persistent JDBC connection, this specifies the JDBC
driver provided by the database.</para>
<para>The .jar containing the JDBC driver belongs in the
<filename>WEB-INF/lib</filename> directory of the deployed OpenAM
instance, and so you should add it to a custom OpenAM .war file that you
deploy.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCDriver</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>JDBC URL</term>
<listitem>
<para>When using Non-persistent JDBC connection, this specifies the URL
to connect to the database.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCUrl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Database Username</term>
<listitem>
<para>Specify the user name to open the database connection.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCDbuser</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Database Password</term>
<listitem>
<para>Specify the password for the user opening the database connection.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCDbpassword</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Password Column Name</term>
<listitem>
<para>Specify the database column name where passwords are stored.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCPasswordColumn</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Prepared Statement</term>
<listitem>
<para>Specify the SQL query to return the password corresponding to the
user to authenticate.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCStatement</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Class to Transform Password Syntax</term>
<listitem>
<para>Specify the class that transforms the password retrieved to the
same format as provided by the user.</para>
<para>The default class expects the password in clear text. Custom
classes must implement the
<literal>JDBCPasswordSyntaxTransform</literal> interface.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCPasswordSyntaxTransformPlugin</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthJDBCAuthLevel</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="ldap-module-conf-hints">
<title>Hints For the LDAP Authentication Module</title>
<para>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
<link xlink:href="http://opendj.org">OpenDJ</link> directory services.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>LDAP</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthLDAPService</literal></para>
<variablelist>
<varlistentry>
<term>Primary LDAP Server</term>
<term>Secondary LDAP Server</term>
<listitem>
<para>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.</para>
<para>Set one primary and optionally one secondary directory server for
each OpenAM server. For the current OpenAM server, specify each directory
server as a
<literal><replaceable>host</replaceable>:<replaceable>port</replaceable></literal>
combination. For other OpenAM servers in the deployment, you can specify
each directory server as
<literal><replaceable>server-name</replaceable>|<replaceable>host</replaceable>:<replaceable>port</replaceable></literal>,
where <replaceable>server-name</replaceable> is the Server Name of the
OpenAM server from the list under Configuration &gt; Servers and
Sites, and <replaceable>host</replaceable>:<replaceable>port</replaceable>
identifies the directory server.</para>
<para>When authenticating users from a directory service that is remote
from OpenAM, set both the primary and secondary server values.</para>
<para>The default port for LDAP is 389. If you are connecting to
the directory over SSL, the default port for LDAP/SSL is 636.</para>
<para>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.</para>
<para><command>ssoadm</command> attributes:
primary is <literal>iplanet-am-auth-ldap-server</literal>,
secondary is <literal>iplanet-am-auth-ldap-server2</literal>, and
<literal>iplanet-am-auth-ldap-ssl-enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>DN to Start User Search</term>
<listitem>
<para>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
<literal>ou=sales,dc=example,dc=com</literal>.</para>
<para>If multiple entries exist with identical search attribute values,
make this value specific enough to return only one entry.</para>
<para><command>ssoadm</command> attribute:
<literal> iplanet-am-auth-ldap-base-dn</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Bind User DN, Bind User Password</term>
<listitem>
<para>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.</para>
<para>The default is <literal>cn=Directory Manager</literal>. 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
<literal>uid=amAdmin,ou=People,<replaceable>OpenAM-deploy-base</replaceable></literal>,
where <replaceable>OpenAM-deploy-base</replaceable> you set during
OpenAM configuration.</para>
<para><command>ssoadm</command> attributes:
<literal>iplanet-am-auth-ldap-bind-dn</literal>,
<literal>iplanet-am-auth-ldap-bind-passwd</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Attributes Used to Search for a User to be Authenticated</term>
<term>User Search Filter</term>
<term>Search Scope</term>
<listitem>
<para>LDAP searches for user entries return entries with attribute
values matching the filter you provide. For example if you search under
<literal>ou=people,dc=example,dc=com</literal> with a filter
<literal>"(mail=bjensen@example.com)"</literal>, then the directory
returns the entry that has <literal>mail=bjensen@example.com</literal>.
In this example the attribute used to search for a user is
<literal>mail</literal>. Multiple attribute values mean the user can
authenticate with any one of the values. For example, if you have
both <literal>uid</literal> and <literal>mail</literal>, then Barbara
Jensen can authenticate with either <literal>bjensen</literal> or
<literal>bjensen@example.com</literal>.</para>
<para>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 <literal>mail</literal> and add User Search Filter
<literal>(objectClass=inetOrgPerson)</literal>, then OpenAM uses the
resulting search filter
<literal>(&amp;(mail=<replaceable>address</replaceable>)(objectClass=inetOrgPerson))</literal>,
where <replaceable>address</replaceable> is the mail address provided
by the user.</para>
<para>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.</para>
<para><command>ssoadm</command> attributes:
<literal>iplanet-am-auth-ldap-user-naming-attribute</literal>,
<literal>iplanet-am-auth-ldap-user-search-attributes</literal>,
<literal>iplanet-am-auth-ldap-search-filter</literal>, and
<literal>iplanet-am-auth-ldap-search-scope</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SSL/TLS Access to LDAP Server</term>
<listitem>
<para>If you enable SSL/TLS, OpenAM must be able to trust LDAP certificates, either because the 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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-ssl-enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Return User DN to Authenticate</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-return-user-dn</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Server Check Interval</term>
<listitem>
<para>Specifies the number of minutes between checks that the primary
LDAP server continues to respond.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-server-check</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User Creation Attributes</term>
<listitem>
<para>This list lets you map (external) attribute names from Active
Directory to (internal) attribute names used by OpenAM.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-ldap-user-creation-attr-list</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Minimum Password Length</term>
<listitem>
<para>Specify the minimum acceptable password length.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-min-password-length</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Behera Password Policy Support</term>
<listitem>
<para>When enabled, support interoperability with servers that implement
the Internet-Draft, <link
xlink:href="http://tools.ietf.org/html/draft-behera-ldap-password-policy-09"
>Password Policy for LDAP Directories</link>.</para>
<para>Support for this Internet-Draft is limited to the LDAP
authentication module. Other components of OpenAM, such as the password
change functionality in the <literal>/idm/EndUser</literal> page, do
not support the Internet-Draft. In general, outside of the LDAP
authentication module, OpenAM binds to the directory server as an
administrator, such as Directory Manager. When OpenAM binds to the
directory server as an administrator rather than as an end user, many
features of the Internet-Draft password policies do not apply.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-behera-password-policy-enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Trust All Server Certificates</term>
<listitem>
<para>When enabled, blindly trust server certificates, including
self-signed test certificates.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-ssl-trust-all</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-ldap-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="membership-module-conf-hints">
<title>Hints For the Membership Authentication Module</title>
<para>The Membership module permits self-registration for new users. You
can then have OpenAM create new user profiles in the identity
repository.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Membership (&amp; self-registration)</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthMembershipService</literal></para>
<variablelist>
<varlistentry>
<term>Minimum Password Length</term>
<listitem>
<para>Specify the minimum acceptable number of characters in the password
provided during self-registration.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-membership-min-password-length</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Default User Roles</term>
<listitem>
<para>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.</para>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-membership-default-roles</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User Status After Registration</term>
<listitem>
<para>If you choose Inactive, then the new user has no access to services
until an administrator activates the account.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-membership-default-user-status</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-membership-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="msisdn-module-conf-hints">
<title>Hints For the MSISDN Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>MSISDN</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthMSISDNService</literal></para>
<variablelist>
<varlistentry>
<term>Trusted Gateway IP Address</term>
<listitem>
<para>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 or IPv6 address here, or leave the list empty to allow
all clients to access the module. If you specify the value
<literal>none</literal>, no clients are allowed access.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNTrustedGatewayList</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>MSISDN Number Search Parameter Name</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNParameterNameList</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Server and Port</term>
<listitem>
<para>The default port for LDAP is 389. If you are connecting to
the directory over SSL, the default port for LDAP/SSL is 636.</para>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNLdapProviderUrl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Start Search DN</term>
<listitem>
<para>Specify the DN of the entry where the search for the user's MSISDN
number should start.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNBaseDn</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Attribute To Use To Search LDAP</term>
<listitem>
<para>Specify the name of the attribute in the user's profile that
contains the MSISDN number to search for the user. The default is
<literal>sunIdentityMSISDNNumber</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNUserSearchAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Server Authentication User</term>
<listitem>
<para>If OpenAM must authenticate to the directory server in order to
search, then specify the bind DN. The default is
<literal>cn=amldapuser,ou=DSAME Users,dc=example,dc=com</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNPrincipalUser</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Server Authentication Password</term>
<listitem>
<para>Specify the password corresponding to the bind DN.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNPrincipalPasswd</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SSL/TLS for LDAP Access</term>
<listitem>
<para>If you choose to use SSL or TLS for security, then make sure that
OpenAM can trust the servers' certificates.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNUseSsl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>MSISDN Header Search Attribute</term>
<listitem>
<para>Specify the headers to use for searching the request for the
MSISDN number.</para>
<itemizedlist>
<listitem>
<para>Cookie Header tells OpenAM to search the cookie.</para>
</listitem>
<listitem>
<para>Request Header tells OpenAM to search the request header.</para>
</listitem>
<listitem>
<para>Request Parameter tells OpenAM to search the request parameters.</para>
</listitem>
</itemizedlist>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNHeaderSearch</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>LDAP Attribute Used to Retrieve User Profile</term>
<listitem>
<para>Specify the LDAP attribute that is used during a search to return
the user profile for MSISDN authentication service. The default is
<literal>uid</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNUserNamingAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Return User DN to DataStore</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNReturnUserDN</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthMSISDNAuthLevel</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="OATH-module-conf-hints">
<title>Hints For the OATH Module</title>
<para>The Open Authentication (OATH) module provides a more secure method for users to
access their accounts with the help of a device, such as their mobile phone or
Yubikey. Users can log into OpenAM and update their information more securely from
a one-time password (OTP) displayed on their device. The OATH module includes the
<link xlink:show="new" xlink:href="http://www.openauthentication.org/about/"
>OATH standard protocols</link> (<link xlink:show="new"
xlink:href="http://tools.ietf.org/html/rfc4226">RFC 4226</link> and
<link xlink:show="new" xlink:href="http://tools.ietf.org/html/rfc6238">
RFC 6238</link>). The OATH module has several enhancements to the
HMAC One-Time Password (HOTP) Authentication Module, but does not replace the original
module for those already using HOTP prior to the 10.1.0 release. The OATH module includes
HOTP authentication and Time-Based One-Time Password (TOTP) authentication. Both types
of authentication require an OATH compliant device that can provide the OTP.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Open Authentication (OATH)</secondary>
</indexterm>
<para> HOTP authentication generates the OTP every time the user requests a new OTP
on their device. The device tracks the number of times the user requests a new OTP, called
the counter. The OTP displays for a period of time you designate in the setup, so the
user may be further in the counter on their device than on their account. OpenAM will resynchronize
the counter when the user finally logs in. To accommodate this, you set the number of
passwords a user can generate before their device cannot be resynchronized. For example, if
you set the number of HOTP Window Size to 50 and a two-year old presses the button 30 on the
user's device to generate a new OTP, the counter in OpenAM will review the OTPs until
it reaches the OTP entered by the user. If the two-year old presses the button 51 times,
you will need to reset the counter to match the number on the device's counter before the
user can login to OpenAM. HOTP authentication does not check earlier passwords, so if the
user attempts to reset the counter on their device, they will not be able to login until
you reset the counter in OpenAM to match their device.</para>
<para>TOTP authentication constantly generates a new OTP based on a time interval you specify.
The device tracks the last two passwords generated and the current password. The Last Login Time
monitors the time when a user logs in to make sure that user is not logged in several times
within the present time period. Once a user log into OpenAM, they must wait for the time it
takes TOTP to generate the next two passwords and display them. This prevents others from
being able to access the users account using the OTP they entered. The user's account can be
accessed again after the generation of the third new OTP is generated and displayed on their
device.For this reason, the TOTP Time-Step Interval should not be so long as to
lock users out, with a recommended time of 30 seconds.</para>
<para>An authentication chain can be created to generate an OTP from
either HOTP or TOTP.</para>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthOATHService</literal></para>
<variablelist>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-auth-level</literal></para></listitem>
</varlistentry>
<varlistentry>
<term>One Time Password Length (in digits)</term>
<listitem>
<para>Set the length of the OTP between 6 and 9 digits long. The default value is 6 digits.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-password-length</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Minimum Secret Key Length</term>
<listitem>
<para>The minimal number of characters required to set the Secret Key.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-min-secret-key-length</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Secret Key Attribute Name</term>
<listitem>
<para>The name of the attribute where the key will be stored in the user profile.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-secret-key-attribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>OATH Algorithm to Use</term>
<listitem>
<para>Select whether to use HOTP or TOTP. You can create an authentication chain to
allow for a greater variety of devices. The default value is HOTP.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-algorithm</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>HOTP Window Size</term>
<listitem>
<para>The number of requests that the system and the device can be off to resynchronize
the password. If a user passes this number of requests before logging
into the system, the password will not work. The default value is 100.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-hotp-window-size</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Counter Attribute Name</term>
<listitem>
<para>The name of the HOTP attribute where the counter will be stored in the user profile.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-hotp-counter-attribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Add Checksum Digit</term>
<listitem>
<para>Adds a checksum digit at the end of the HOTP password to verify it was entered correctly.
The default value is No.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-add-checksum</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Truncation Offset</term>
<listitem>
<para>Advanced feature that is device specific. Any value below 0 or above 15 will turn off
the functionality. The default value is -1. If not required by the device, leave at the default
setting.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-truncation-offset</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>TOTP Time Step Interval</term>
<listitem>
<para>Defines how long the password will appear on the user's device (in seconds).
We recommend keeping this number low, for example 30 seconds, because once a user
logs out, they will not be able to login again until two full time cycles have passed.
The default value is 30 seconds.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-size-of-time-step</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>TOTP Time Steps</term>
<listitem>
<para>The number of requests that the system and the device can be off to resynchronize
the password. If a user passes this number of requests before logging into the system,
the password will not work. The default value is 2.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-steps-in-window</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Last Login Time Attribute</term>
<listitem>
<para>The name of the attribute where both HOTP and TOTP authentication will store information
on when a person last logged in.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oath-last-login-time-attribute-name</literal></para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="oauth2-module-conf-hints">
<title>Hints For the OAuth 2.0 Authentication Module</title>
<para>The OAuth 2.0 authentication module lets OpenAM authenticate clients
of OAuth resource servers. References in this section are to RFC 6749, <link
xlink:href="http://tools.ietf.org/html/rfc6749" xlink:show="new">The OAuth
2.0 Authorization Framework</link>.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>OAuth 2.0</secondary>
</indexterm>
<indexterm>
<primary>OAuth 2.0</primary>
</indexterm>
<note>
<para>The default settings are for Facebook.</para>
</note>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthOAuthService</literal></para>
<variablelist>
<varlistentry>
<term>Client ID</term>
<listitem>
<para>OAuth <literal>client_id</literal> as described in
<link xlink:href="http://tools.ietf.org/html/rfc6749#section-2.2"
xlink:show="new">section 2.2 of RFC 6749</link>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-client-id</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Client Secret</term>
<listitem>
<para>OAuth <literal>client_secret</literal> as described in
<link xlink:href="http://tools.ietf.org/html/rfc6749#section-2.3"
xlink:show="new">section 2.3 of RFC 6749</link>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-client-secret</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Endpoint URL</term>
<listitem>
<para>URL to the end point handling OAuth authentication as described in
<link xlink:href="http://tools.ietf.org/html/rfc6749#section-3.1"
xlink:show="new">section 3.1 of RFC 6749</link>. The default value is
<literal>https://www.facebook.com/dialog/oauth</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-auth-service</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Access Token Endpoint URL</term>
<listitem>
<para>URL to the end point handling access tokens as described in
<link xlink:href="http://tools.ietf.org/html/rfc6749#section-3.2"
xlink:show="new">section 3.2 of RFC 6749</link>. The default value is
<literal>https://graph.facebook.com/oauth/access_token</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-token-service</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User Profile Service URL</term>
<listitem>
<para>User profile URL that returns profile information in JSON
format. The default value is
<literal>https://graph.facebook.com/me</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-user-profile-service</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Scope</term>
<listitem>
<para>Comma separated list of user profile attributes that the application
requires. The default value is <literal>email,read_stream</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-scope</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Proxy URL</term>
<listitem>
<para>URL to the <filename>/oauth2c/OAuthProxy.jsp</filename> file,
part of OpenAM.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-sso-proxy-url</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Account Mapper</term>
<listitem>
<para>Class implementing account mapping. The default value is
<literal>org.forgerock.openam.authentication.modules.oauth2.DefaultAccountMapper</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-account-mapper</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Account Mapper Configuration</term>
<listitem>
<para>Map of OAuth Provider user account attributes used to find the
local profile of the authenticated user, with values in the form
<literal><replaceable>provider-attr</replaceable>=<replaceable>local-attr</replaceable></literal>.
Default values <literal>email=mail</literal> and <literal> id=facebook-id</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-account-mapper-configuration</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Attribute Mapper</term>
<listitem>
<para>Class implementing attribute mapping. Default:
<literal>org.forgerock.openam.authentication.modules.oauth2.DefaultAttributeMapper</literal></para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-attribute-mapper</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Attribute Mapper Configuration</term>
<listitem>
<para>Map of OAuth Provider user account attributes to local user profile
attributes, with values in the form
<literal><replaceable>provider-attr</replaceable>=<replaceable>local-attr</replaceable></literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-attribute-mapper-configuration</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Save attributes in the session</term>
<listitem>
<para>When enabled, add the mapped attributes to the session saved. The
default mode is <literal>Enabled</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-save-attributes-to-session-flag</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Email attribute in OAuth2 Response</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-mail-attribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Create account if it does not exist</term>
<listitem>
<para>When enabled, if the user profile does not exist, optionally
retrieve a password and activation code from the user, and then create
the profile. The default mode is <literal>Enabled</literal>.</para>
<para>When the OAuth 2.0 client is configured to create new accounts,
the SMTP settings must also be valid. As part of account creation,
the OAuth 2.0 client authentication module sends the resource owner
an email with an account activation code. To send the mail, OpenAM
uses the SMTP settings you provide here in the OAuth 2.0 client
configuration.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-createaccount-flag</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Prompt for password setting and activation code</term>
<listitem>
<para>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. The default mode is <literal>Enabled</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-prompt-password-flag</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Map to anonymous user</term>
<listitem>
<para>When enabled, map the OAuth authenticated user to the anonymous
user you specify. No account is created, even if Create account if it
does not exist is enabled.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-map-to-anonymous-flag</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Anonymous User</term>
<listitem>
<para>Specifies an anonymous user that exists in the current realm. The
default is <literal>anonymous</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-anonymous-user</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>OAuth 2.0 Provider logout service</term>
<listitem>
<para>Specifies the optional URL of the OAuth Provider.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-logout-service-url</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Logout options</term>
<listitem>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-logout-behaviour</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mail Server Gateway implementation class</term>
<listitem>
<para>Class to interact with the mail server. Default:
<literal>org.forgerock. openam.authentication.modules.oauth2.DefaultEmailGatewayImpl</literal></para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-email-gwy-impl</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SMTP host</term>
<listitem>
<para>Host name of the mail server. The default is
<literal>localhost</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-smtp-hostname</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SMTP port</term>
<listitem>
<para>SMTP port number for the mail server. The default value is
<literal>25</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-smtp-port</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SMTP User Name</term>
<listitem>
<para>If the mail server requires authentication to send mail, specifies
the user name.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-smtp-username</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SMTP User Password</term>
<listitem>
<para>If the mail server requires authentication to send mail, specifies
the password.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-smtp-password</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SMTP SSL Enabled</term>
<listitem>
<para>When enabled, connect to the mail server over SSL. OpenAM must be
able to trust the SMTP server certificate.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-smtp-ssl_enabled</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SMTP From address</term>
<listitem>
<para>Specifies the message sender address, such as
<literal>no-reply@example.com</literal>. The default value is
<literal>info@forgerock.com</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>org-forgerock-auth-oauth-smtp-email-from</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-oauth-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
<para>The following tables show endpoint URLs for OpenAM when <link
xlink:href="admin-guide#chap-oauth2"
xlink:role="http://docbook.org/xlink/role/olink">configured as an
OAuth 2.0 provider</link>, and also URLs for large OAuth 2.0 providers.
The default endpoints are for Facebook as the OAuth 2.0 provider.</para>
<para>In addition to the endpoint URLs you can set other fields, like scope
and attribute mapping, depending on the provider you use.</para>
<table xml:id="oauth2-openam" pgwide="1">
<title>Endpoint URLs for OpenAM</title>
<tgroup cols="2">
<thead>
<row>
<entry>OpenAM Field</entry>
<entry>Details</entry>
</row>
</thead>
<tbody>
<row>
<entry>Authentication Endpoint URL</entry>
<entry>
<para><literal>/oauth2/authorize</literal> under the deployment
URL.<footnote xml:id="oauth2-realms-footnote">
<para>This OpenAM endpoint can take additional parameters. In
particular you must specify the realm if the OpenAM OAuth 2.0
provider is configured for a subrealm rather than / (Top-Level
Realm).</para>
<para>For example, if the OAuth 2.0 provider is configured for the
realm <literal>/customers</literal>, then the authentication endpoint
URL is as follows:
<literal>https://openam.example.com:8443/openam/oauth2/authorize?realm=/customers</literal></para>
<para>The <literal>/oauth2/authorize</literal> endpoint can also take
<literal>module</literal> and <literal>service</literal> parameters.
Use either as described in <link
xlink:href="admin-guide#authn-from-browser"
xlink:role="http://docbook.org/xlink/role/olink"><citetitle
>Authenticating To OpenAM</citetitle></link>, where
<literal>module</literal> specifies the authentication module
instance to use or <literal>service</literal> specifies the
authentication chain to use when authenticating the resource
owner.</para>
</footnote>
</para>
<para>Example: <literal
>https://openam.example.com:8443/openam/oauth2/authorize</literal>.</para>
</entry>
</row>
<row>
<entry>Access Token Endpoint URL</entry>
<entry>
<para><literal>/oauth2/access_token</literal> under the deployment
URL.<footnoteref linkend="oauth2-realms-footnote" /></para>
<para>Example: <literal
>https://openam.example.com:8443/openam/oauth2/access_token</literal>.</para></entry>
</row>
<row>
<entry>User Profile Service URL</entry>
<entry>
<para><literal>/oauth2/tokeninfo</literal> under the deployment URL.</para>
<para>Example: <literal
>https://openam.example.com:8443/openam/oauth2/tokeninfo</literal>.</para></entry>
</row>
</tbody>
</tgroup>
</table>
<table xml:id="oauth2-facebook" pgwide="1">
<title>Endpoint URLs for Facebook</title>
<tgroup cols="2">
<thead>
<row>
<entry>OpenAM Field</entry>
<entry>Details</entry>
</row>
</thead>
<tbody>
<row>
<entry>Authentication Endpoint URL</entry>
<entry>https://www.facebook.com/dialog/oauth</entry>
</row>
<row>
<entry>Access Token Endpoint URL</entry>
<entry>https://graph.facebook.com/oauth/access_token</entry>
</row>
<row>
<entry>User Profile Service URL</entry>
<entry>https://graph.facebook.com/me</entry>
</row>
<row>
<entry>OAuth 2.0 Provider logout service</entry>
<entry>http://www.facebook.com/logout.php</entry>
</row>
</tbody>
</tgroup>
</table>
<table xml:id="oauth2-google" pgwide="1">
<title>Endpoint URLs for Google</title>
<tgroup cols="2">
<thead>
<row>
<entry>OpenAM Field</entry>
<entry>Details</entry>
</row>
</thead>
<tbody>
<row>
<entry>Authentication Endpoint URL</entry>
<entry>https://accounts.google.com/o/oauth2/auth</entry>
</row>
<row>
<entry>Access Token Endpoint URL</entry>
<entry>https://accounts.google.com/o/oauth2/token</entry>
</row>
<row>
<entry>User Profile Service URL</entry>
<entry>https://www.googleapis.com/oauth2/v1/userinfo</entry>
</row>
<row>
<entry>OAuth 2.0 Provider logout service</entry>
<entry>https://mail.google.com/mail/?logout</entry>
</row>
</tbody>
</tgroup>
</table>
<table xml:id="oauth2-msn" pgwide="1">
<title>Endpoint URLs for MSN</title>
<tgroup cols="2">
<thead>
<row>
<entry>OpenAM Field</entry>
<entry>Details</entry>
</row>
</thead>
<tbody>
<row>
<entry>Authentication Endpoint URL</entry>
<entry>https://oauth.live.com/authorize</entry>
</row>
<row>
<entry>Access Token Endpoint URL</entry>
<entry>https://oauth.live.com/token</entry>
</row>
<row>
<entry>User Profile Service URL</entry>
<entry>https://apis.live.net/v5.0/me</entry>
</row>
<row>
<entry>OAuth 2.0 Provider logout service</entry>
<entry>http://oauth.live.com/logout</entry>
</row>
</tbody>
</tgroup>
</table>
<!-- Waiting for User Profile Service URL info from Twitter
<table xml:id="oauth2-twitter" pgwide="1">
<title>Endpoint URLs for Twitter</title>
<tgroup cols="2">
<thead>
<row>
<entry>OpenAM Field</entry>
<entry>Details</entry>
</row>
</thead>
<tbody>
<row>
<entry>Authentication Endpoint URL</entry>
<entry>https://api.twitter.com/oauth/authenticate</entry>
</row>
<row>
<entry>Access Token Endpoint URL</entry>
<entry>https://api.twitter.com/oauth/request_token</entry>
</row>
<row>
<entry>User Profile Service URL</entry>
<entry>STILL NEED</entry>
</row>
<row>
<entry>OAuth 2.0 Provider logout service</entry>
<entry>TODO</entry>
</row>
</tbody>
</tgroup>
</table>
-->
</section>
<section xml:id="radius-module-conf-hints">
<title>Hints For the RADIUS Authentication Module</title>
<para>The Remote Authentication Dial-In User Service (RADIUS) module lets
OpenAM authenticate users against RADIUS servers.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>RADIUS</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthRadiusService</literal></para>
<variablelist>
<varlistentry>
<term>Primary Radius Servers, Secondary Radius Servers</term>
<listitem>
<para>Specify the IP address or fully qualified domain name of the
primary RADIUS server. The default is <literal>127.0.0.1</literal>
(localhost loopback).</para>
<para><command>ssoadm</command> attribute:
<literal>primary is iplanet-am-auth-radius-server1</literal>;
secondary is <literal>iplanet-am-auth-radius-server2</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Shared Secret</term>
<listitem>
<para>Specify the shared secret for RADIUS authentication. The shared
secret should be as secure as a well-chosen password.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-radius-secret</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Port Number</term>
<listitem>
<para>Specify the RADIUS server port. Default is 1645.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-radius-server-port</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Timeout</term>
<listitem>
<para>Specify how many seconds to wait for the RADIUS server to respond.
The default value is 3 seconds.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-radius-timeout</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Health check interval</term>
<listitem>
<para>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</para>
<para><command>ssoadm</command> attribute:
<literal>openam-auth-radius-healthcheck-interval</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-radius-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="sae-module-conf-hints">
<title>Hints For the SAE Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Secure Attribute Exchange (SAE)</secondary>
</indexterm>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthSAEService</literal></para>
<variablelist>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunAMAuthSAEAuthLevel</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="securid-module-conf-hints">
<title>Hints For the SecurID Authentication Module</title>
<para>The SecurID module lets OpenAM authenticate users with RSA
Authentication Manager software and RSA SecurID authenticators.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>SecurID</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthSecurIDService</literal></para>
<variablelist>
<varlistentry>
<term>ACE/Server Configuration Path</term>
<listitem>
<para>Specify the directory in which the SecurID ACE/Server
<filename>sdconf.rec</filename> file is located, which by default is
expected under the configuration directory for OpenAM, such as
<filename>$HOME/openam/openam/auth/ace/data</filename>. The directory
must exist before OpenAM can use SecurID authentication.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-securid-server-config-path</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-securid-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="desktop-module-conf-hints">
<title>Hints For the Windows Desktop SSO Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Kerberos</secondary>
</indexterm>
<indexterm>
<primary>Authentication</primary>
<secondary>Windows Desktop SSO</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthWindowsDesktopSSOService</literal></para>
<variablelist>
<varlistentry>
<term>Service Principal</term>
<listitem>
<para>Specify the Kerberos principal for authentication in the following
format.</para>
<literallayout class="monospaced">HTTP/<replaceable>host</replaceable>.<replaceable>domain</replaceable>@<replaceable>dc-domain-name</replaceable></literallayout>
<para>Here, <replaceable>host</replaceable> and
<replaceable>domain</replaceable> correspond to the host and domain names
of the OpenAM instance, and <replaceable>dc-domain-name</replaceable>
is the domain name of the Windows Kerberos domain controller server.
The <replaceable>dc-domain-name</replaceable> can differ from the domain
name for OpenAM.</para>
<para>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.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-windowsdesktopsso-principal-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Keytab File Name</term>
<listitem>
<para>Specify the full path of the keytab file for the Service Principal.
You generate the keytab file using the Windows <command>ktpass</command>
utility.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-windowsdesktopsso-keytab-file</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Kerberos Realm</term>
<listitem>
<para>Specify the Kerberos Key Distribution Center realm. For the
Windows Kerberos service this is the domain controller server domain
name.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-windowsdesktopsso-kerberos-realm</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Kerberos Server Name</term>
<listitem>
<para>Specify the fully qualified domain name of the Kerberos Key
Distribution Center server, such as that of the domain controller
server.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-windowsdesktopsso-kdc</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Return Principal with Domain Name</term>
<listitem>
<para>When enabled, OpenAM automatically returns the Kerberos principal
with the domain controller's domain name during authentication.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-windowsdesktopsso-returnRealm</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-windowsdesktopsso-auth-level</literal></para></listitem>
</varlistentry>
<varlistentry>
<term>Search for the user in the realm</term>
<listitem>
<para>Validates the user against the configured data stores. If the user from the
Kerberos token is not found, authentication will fail. If an authentication
chain is set, the user will be able to authenticate through another module.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-windowsdesktopsso-lookupUserInRealm</literal></para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="winnt-module-conf-hints">
<title>Hints For the Windows NT Authentication Module</title>
<para>The Windows NT module lets OpenAM authenticate against a Microsoft
Windows NT server.</para>
<para>This module requires that you install a Samba client in a
<filename>bin</filename> directory under the OpenAM configuration directory
such as <filename>$HOME/openam/openam/bin</filename>.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>Windows NT</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>iPlanetAMAuthNTService</literal></para>
<variablelist>
<varlistentry>
<term>Authentication Domain</term>
<listitem>
<para>Specify the Windows domain name to which users belong.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-nt-domain</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Host</term>
<listitem>
<para>Specify the NetBIOS name of the Windows NT host to which to
authenticate users.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-nt-host</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Samba Configuration File Name</term>
<listitem>
<para>Specify the full path to the Samba configuration file.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-samba-config-file-name</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>iplanet-am-auth-nt-auth-level</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="wss-module-conf-hints">
<title>Hints For the WSSAuth Authentication Module</title>
<para>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.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>WSSAuth</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>sunAMAuthWSSAuthModuleService</literal></para>
<variablelist>
<varlistentry>
<term>User search attribute</term>
<listitem>
<para>Specify a user attribute to search for a user. Default is
<literal>uid</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>sunWebservicesUserSearchAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User realm</term>
<listitem>
<para>Specify the realm to which users belong. For the OpenAM Security
Token Service, this is <literal>/</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>sunWebServicesUserRealm</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>User password attribute</term>
<listitem>
<para>Specify the password attribute or that of the password equivalent.
The default is <literal>userPassword</literal>.</para>
<para><command>ssoadm</command> attribute:
<literal>sunWebservicesUserPasswordAttribute</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Authentication Level</term>
<listitem>
<para>Sets the authentication level used to indicate the level of security
associated with the module. The value can range from 0 to any positive integer.</para>
<para><command>ssoadm</command> attribute:
<literal>sunWebservicesAuthenticationLevel</literal></para></listitem>
</varlistentry>
</variablelist>
</section>
<!-- <section xml:id="yubikey-module-conf-hints">
<title>Hints For the YubiKey Authentication Module</title>
<para>Use the following hints to configure the module.</para>
<indexterm>
<primary>Authentication</primary>
<secondary>YubiKey</secondary>
</indexterm>
<para><command>ssoadm</command> service name:
<literal>TODO</literal></para>
<variablelist>
<varlistentry>
<term>TODO</term>
<listitem>
<para>TODO</para>
</listitem>
</varlistentry>
</variablelist>
</section> -->
</section>
<section xml:id="configure-authn-chains">
<title>Configuring Authentication Chains</title>
<indexterm>
<primary>Authentication</primary>
<secondary>Chains</secondary>
</indexterm>
<para>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.</para>
<procedure xml:id="create-authn-chain">
<title>To Create an Authentication Chain</title>
<step>
<para>On the Access Control tab page of the OpenAM console, click the
realm for which to create the authentication chain.</para>
</step>
<step>
<para>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.</para>
</step>
<step>
<para>Give the new authentication chain a name, and add instances of the
modules to use in the chain.</para>
</step>
<step>
<para>Assign at least criteria (optional, required, requisite, sufficient)
as described above in <xref linkend="what-is-authn" />. You can also
configure where OpenAM redirects the user upon successful and failed
authentication, and plug in your post-authentication processing classes
as necessary.</para>
</step>
<!-- Fix for OPENAM-1063: Document module-credential sharing properties -->
<step performance="optional">
<para>If you need modules in the chain to share user credentials, then set
options for the module.</para>
<variablelist>
<varlistentry>
<term><option>iplanet-am-auth-shared-state-enabled</option></term>
<listitem>
<para>Set <literal>iplanet-am-auth-shared-state-enabled=true</literal>
to allow subsequent modules in the authentication chain to use
the credentials, such as user name and password, captured by this
module. (Default: <literal>true</literal>)</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>iplanet-am-auth-store-shared-state-enabled</option></term>
<listitem>
<para>Set <literal>iplanet-am-auth-store-shared-state-enabled=true</literal>
to store the captured credentials. Shared state is cleared when the
user successfully authenticates, quits the chain, or logs out.
(Default: <literal>false</literal>)</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>iplanet-am-auth-shared-state-behavior-pattern</option></term>
<listitem>
<para>Set <literal>iplanet-am-auth-shared-state-behavior-pattern=tryFirstPass</literal>
(the default) to try authenticating with the captured password. If
authentication fails, then OpenAM prompts the user for the credentials
again.</para>
<para>Set <literal>iplanet-am-auth-shared-state-behavior-pattern=useFirstPass</literal>
to authenticate with the captured password. If authentication fails,
then the module fails.</para>
</listitem>
</varlistentry>
</variablelist>
<para>For example, consider a chain with two modules sharing credentials
according to the default settings. The first module in the chain has the
option <literal>iplanet-am-auth-shared-state-enabled=true</literal>, and
criteria <literal>REQUIRED</literal>. The second module in the chain has
options <literal>iplanet-am-auth-shared-state-enabled=true</literal>,
<literal>iplanet-am-auth-shared-state-behavior-pattern=tryFirstPass</literal>,
and criteria <literal>REQUIRED</literal>. 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.</para>
</step>
<step>
<para>Save your work.</para>
</step>
</procedure>
<procedure xml:id="set-default-authn-chain">
<title>To Select the Default Chain</title>
<para>Before you select the default chain for users, and especially for
administrators, test the authentication chain first. For example,
<literal>http://openam.example.com:8080/openam/UI/Login?service=NewChain</literal>.
If you cannot log in, then go back and fix the authentication chain's
configuration before making it the default.</para>
<step>
<para>On the Access Control tab page of the OpenAM console, click the
realm for which to set the default authentication chain.</para>
</step>
<step performance="optional">
<para>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.</para>
<para>The Organization Authentication Configuration serves when users
access <literal>/openam/UI/Login</literal>.</para>
<para>The Administrator Authentication Configuration serves when users
access <literal>/openam/console</literal>.</para>
<para>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, <literal>amadmin</literal> can login at
<literal>/openam/UI/Login</literal>. You can change that for your
deployment.</para>
</step>
<step>
<para>Save your work.</para>
</step>
</procedure>
</section>
<section xml:id="authn-post-auth-plugins">
<title>Post Authentication Plugins</title>
<indexterm>
<primary>Post authentication plugins</primary>
</indexterm>
<para>Post authentication plugins include custom processing at the end of the
authentication process, immediately before the subject is authenticated.
Common uses of post authentication plugins include setting cookies and
session variables. Post authentication plugins are often used in conjunction
with policy agents. The post authentication plugin sets custom session
properties, and then the policy agent injects the custom properties into the
request header to the protected application.</para>
<para>In the OpenAM console, you add post authentication plugins to an
authentication chain by adding their class names to the Post Authentication
Processing Class list under Access Control &gt; <replaceable>Realm
Name</replaceable> &gt; Authentication &gt; Authentication Chaining &gt;
<replaceable>Auth Chain Name</replaceable>.</para>
<variablelist>
<title>Standard Post Authentication Plugins</title>
<para>OpenAM provides some post authentication plugins as part of the
standard product delivery.</para>
<varlistentry>
<term>Class name: <literal>org.forgerock.openam.authentication.modules.adaptive.Adaptive</literal></term>
<listitem>
<para>The adaptive authentication plugin serves to save cookies and profile
attributes after successful authentication.</para>
<para>Add it to your authentication chains that use the adaptive
authentication module configured to save cookies and profile
attributes.</para>
</listitem>
</varlistentry>
<!-- OPENAM-1861: Document OAuth2 Post Authentication plugin -->
<varlistentry>
<term>Class name: <literal>org.forgerock.openam.authentication.modules.oauth2.OAuth2PostAuthnPlugin</literal></term>
<listitem>
<para>The OAuth 2.0 post authentication plugin builds a global logout URL
used by <filename>/oauth2c/OAuthLogout.jsp</filename> after successful
OAuth 2.0 client authentication. This logs the resource owner out
with the OAuth 2.0 provider when logging out of OpenAM.</para>
<para>Before using this plugin, configure the OAuth 2.0 authentication
module with the correct OAuth 2.0 Provider logout service URL, and set
the Logout options to Log out or Prompt. This plugin cannot succeed unless
those parameters are correctly set.</para>
<para>Sometimes OAuth 2.0 providers change their endpoints, including
their logout URLs. When using a provider like Facebook, Google, or MSN
make sure you are aware when they change their endpoint locations so that
you can change your client configuration accordingly.</para>
</listitem>
</varlistentry>
<!-- OPENAM-1860: Document post authentication plugin account expiration -->
<varlistentry>
<term>Class name: <literal>org.forgerock.openam.authentication.plugins.AccountExpirePlugin</literal></term>
<listitem>
<para>The account expiration post authentication plugin sets an account
expiration date after successful authentication. OpenAM uses this to
prevent expired accounts from being used to authenticate.</para>
<para>The default of 30 days can be changed using the advanced OpenAM
server property,
<literal>org.forgerock.openam.authentication.accountExpire.days</literal>.</para>
</listitem>
</varlistentry>
</variablelist>
<para>If necessary, you can also write your own custom post authentication
plugin as described in the <citetitle>Developer's Guide</citetitle> chapter
on <link xlink:href="dev-guide#chap-post-auth"
xlink:role="http://docbook.org/xlink/role/olink"><citetitle>Creating a Post
Authentication Plugin</citetitle></link>.</para>
</section>
<section xml:id="authn-from-browser">
<title>Authenticating To OpenAM</title>
<para>This section explains how to connect to OpenAM for user authentication
by adding parameters to the login URL when testing your configuration.</para>
<para>The base URL to authenticate to OpenAM points to
<literal>/UI/Login</literal> under the deployment URL, such as
<literal>http://openam.example.com:8080/openam/UI/Login</literal>.
<footnote><para>The base URL to logout is similar, for example
<literal>http://openam.example.com:8080/openam/UI/Logout</literal>.</para>
</footnote> You can, however, specify parameters in the query string
of the URL to request a specific authentication configuration. For example,
<literal>http://openam.example.com:8080/openam/UI/Login?module=LDAP</literal>
requests that OpenAM use the LDAP authentication module.</para>
<variablelist>
<para>OpenAM accepts the following parameters in the query string. With
the exception of <literal>IDToken</literal> parameters, use no more than
one occurrence of each.</para>
<varlistentry>
<term>arg=newsession</term>
<listitem>
<para>Request that OpenAM end the user's current session and start a
new session.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?arg=newsession</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>authlevel</term>
<listitem>
<para>Request that OpenAM authenticate the user using a module with at
least the specified authentication level that you have configured.</para>
<para>As this parameter determines authentication module selection, do
not use it with <literal>module</literal>, <literal>service</literal>,
or <literal>user</literal>.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?authlevel=1</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>ForceAuth</term>
<listitem>
<para>If <literal>ForceAuth=true</literal>, request that OpenAM force the
user to authenticate even if she already has a valid session. On
successful authentication, OpenAM updates the session token.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?ForceAuth=true</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>goto</term>
<listitem>
<para>On successful authentication, or successful logout, request that
OpenAM redirect the user to the specified location. Values must be
URL encoded.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?goto=http%3A%2F%2Fwww.example.com%2Fsuccess.html</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>gotoOnFail</term>
<listitem>
<para>On authentication failure, request that OpenAM redirect the user to
the specified location. Values must be URL encoded.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?goto=http%3A%2F%2Fwww.example.com%2Ffailure.html</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>IDToken1, IDToken2, ..., IDTokenN</term>
<listitem>
<para>Pass the specified credentials as <literal>IDToken</literal>
parameters in the URL. The <literal>IDToken</literal> credentials map
to the fields in the login page for the authentication module, such as
<literal>IDToken1</literal> as user ID and <literal>IDToken2</literal>
as password for basic user name, password authentication. The order
depends on the callbacks in login page for the module;
<literal>IDTokenN</literal> represents the N<superscript>th</superscript>
callback of the login page.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?IDToken1=bjensen&amp;IDToken2=hifalutin</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>iPSPCookie=yes</term>
<listitem>
<para>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.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?iPSPCookie=yes</literal></para>
<para>OpenAM sets an <literal>DProPCookie</literal> that persists until
expiry. The following screen shot shows an example.</para>
<mediaobject xml:id="figure-persistent-dpropcookie">
<alt>DProPCookie shown in the browser</alt>
<imageobject>
<imagedata fileref="images/persistent-dpropcookie.png" format="PNG" />
</imageobject>
</mediaobject>
<para>An alternative persistent cookie mechanism extends the lifetime of
the normal <literal>iPlanetDirectoryPro</literal> using the advanced
server settings, <literal>openam.session.persist_am_cookie</literal>
or <literal>openam.session.allow_persist_am_cookie</literal>, and
<literal>com.iplanet.am.cookie.timeToLive</literal>.</para>
<para>To set the mechanism globally for the server, browse in the OpenAM
console to Configuration &gt; Servers and Sites &gt; <replaceable>Server
Name</replaceable> &gt; Advanced, and then set
<literal>openam.session.persist_am_cookie</literal> to
<literal>true</literal> and
<literal>com.iplanet.am.cookie.timeToLive</literal> to the cookie lifetime
in seconds.</para>
<para>To allow users to use this mechanism on a per-session basis,
browse in the OpenAM console to Configuration &gt; Servers and
Sites &gt; <replaceable>Server Name</replaceable> &gt; Advanced, and then
set <literal>openam.session.allow_persist_am_cookie</literal> to
<literal>true</literal> and
<literal>com.iplanet.am.cookie.timeToLive</literal> 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 &gt; Global
&gt; Session &gt; Dynamic Attributes, or per realm under Access Control
&gt; <replaceable>Realm Name</replaceable> &gt; Services &gt; Session.
Then, to request the cookie, use
<literal>openam.session.persist_am_cookie=Yes</literal> as one of the
query string parameters in the login URL.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>locale</term>
<listitem>
<para>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.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?locale=fr</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>module</term>
<listitem>
<para>Request that OpenAM use the authentication module instance as
configured for the realm where the user is authenticating.</para>
<para>As this parameter determines authentication module selection, do
not use it with <literal>authlevel</literal>, <literal>service</literal>,
or <literal>user</literal>.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?module=DataStore</literal></para>
</listitem>
</varlistentry>
<!--
<varlistentry>
<term>PersistAMCookie=yes</term>
<listitem>
<para>Request that OpenAM save the cookie to memory so that another
application on the user's system can read it to create an
<literal>SSOToken</literal>.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?PersistAMCookie=yes</literal></para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term>realm</term>
<listitem>
<para>Request that OpenAM authenticate the user to the specified realm.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?realm=sales</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>service</term>
<listitem>
<para>Request that OpenAM authenticate the user with the specified
authentication chain.</para>
<para>As this parameter determines authentication module selection, do
not use it with <literal>authlevel</literal>, <literal>module</literal>,
or <literal>user</literal>.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?service=ExternalChain</literal></para>
</listitem>
</varlistentry>
<varlistentry>
<term>user</term>
<listitem>
<para>Request that the user, specified by her OpenAM universal ID,
authenticate according to the chain specified in her profile.</para>
<para>As this parameter determines authentication module selection, do
not use it with <literal>authlevel</literal>, <literal>module</literal>,
or <literal>service</literal>.</para>
<para>Example: <literal>http://openam.example.com:8080/openam/UI/Login?user=admin</literal></para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="configure-account-lockout">
<title>Configuring Account Lockout</title>
<indexterm>
<primary>Account lockout</primary>
</indexterm>
<itemizedlist>
<para>OpenAM supports two different approaches to <firstterm>account
lockout</firstterm>, where OpenAM locks an account after repeated
authentication failures. Lockout works with modules for which users
can enter a password incorrectly.</para>
<listitem>
<para>Memory lockout locks the user account, keeping track of the locked
state only in memory, and then unlocking the account after a specified
delay. Memory lockout is also released when OpenAM restarts.</para>
</listitem>
<listitem>
<para>Persistent (physical) lockout sets the user account status to
<literal>inactive</literal> in the user profile. For persistent lockout,
OpenAM tracks failed authentication attempts by writing to the user
repository.</para>
<para>Persistent account lockout works independently of account lockout
mechanisms in the underlying directory server that serves as the user
data store.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<para>You configure account lockout by editing settings for the <link
xlink:href="admin-guide#core-module-conf-hints"
xlink:role="http://docbook.org/xlink/role/olink">core authentication
module</link>. Access the settings in OpenAM console under Access Control
&gt; <replaceable>Realm Name</replaceable> &gt; Authentication &gt; All
Core Settings..., and then scroll down to the Account Lockout section.
The inline help explains the settings in detail.</para>
<listitem>
<para>Enable lockout by checking Login Failure Lockout Mode, setting
the number of attempts, and setting the lockout interval and
duration.</para>
<para>You can also opt to warn users after several consecutive failures,
or to multiply the lockout duration on each successive lockout.</para>
</listitem>
<listitem>
<para>You can set up email notification upon lockout to an administrator
if OpenAM is configured to send mail. (Servers and Sites &gt; <replaceable
>Server Name</replaceable> &gt; General &gt; Mail Server.)</para>
</listitem>
<listitem>
<para>For persistent lockout, OpenAM sets the value of the user's
<literal>inetuserstatus</literal> profile attribute to
<literal>inactive</literal>. You can also specify another attribute to
update on lockout. You can further set a non-default attribute on which
to store the number of failed authentication attempts. When you do store
the number of failed attempts in the data store, other OpenAM servers
accessing the user data store can also see the number.</para>
</listitem>
</itemizedlist>
<para>If you need to unlock a user's account, find the user under Access
Control &gt; <replaceable>Realm Name</replaceable> &gt; Subjects &gt; User,
set the user's User Status to Active, and click Save.</para>
</section>
<section xml:id="configure-session-quotas">
<title>Configuring Session Quotas</title>
<indexterm>
<primary>Session quotas</primary>
</indexterm>
<para>OpenAM lets you limit the number of active sessions for a user by
setting session quotas. You also configure session quota exhaustion actions
so that when a user goes beyond the session quota, OpenAM takes the
appropriate action.</para>
<important>
<para>To enforce session quotas across multiple servers in a site, configure
session failover as described in the <citetitle>Installation Guide</citetitle>
chapter, <link xlink:href="install-guide#chap-session-failover"
xlink:role="http://docbook.org/xlink/role/olink"><citetitle>Setting Up OpenAM
Session Failover</citetitle></link>.</para>
</important>
<procedure xml:id="session-quotas-and-exhaustion-actions">
<title>To Configure Session Quotas &amp; Exhaustion Actions</title>
<!-- This is based on Peter Major's work. See his blog entry on the subject:
http://blogs.forgerock.org/petermajor/2013/01/session-quota-basics/ -->
<para>The session quota applies to all sessions opened for the same
user (as represented by the user's universal identifier).</para>
<step>
<para>Log in to OpenAM Console as administrator, and then browse to
Configuration &gt; Global &gt; Session.</para>
</step>
<step>
<para>Set Enable Quota Constraints to <literal>ON</literal>.</para>
</step>
<step>
<para>Set Resulting behavior if session quota exhausted.</para>
<variablelist>
<para>The following settings are available by default.</para>
<varlistentry>
<term><literal>DENY_ACCESS</literal></term>
<listitem>
<para>Deny access, preventing the user from creating an additional
session.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>DESTROY_NEXT_EXPIRING</literal></term>
<listitem>
<para>Remove the next session to expire, and create a new session for
the user. The next session to expire is the session with the minimum
time left until expiration.</para>
<para>This is the default setting.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>DESTROY_OLDEST_SESSION</literal></term>
<listitem>
<para>Remove the oldest session, and create a new session for the
user.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>DESTROY_OLD_SESSIONS</literal></term>
<listitem>
<para>Remove all existing sessions, and create a new session for the
user.</para>
</listitem>
</varlistentry>
</variablelist>
<para>If none of these session quota exhaustion actions fit your deployment,
you can implement a custom session quota exhaustion action. See the
<citetitle>Developer's Guide</citetitle> chapter on <link
xlink:href="dev-guide#chap-custom-quota-exhaustion-action"
xlink:role="http://docbook.org/xlink/role/olink"><citetitle>Customizing
Session Quota Exhaustion Actions</citetitle></link> for an example.</para>
</step>
<step>
<para>Set Active User Sessions to the session quota.</para>
<para>The default is 5 sessions.</para>
</step>
<step>
<para>Save your work.</para>
</step>
<step performance="optional">
<para>If you have multiple servers but session failover is not configured,
configure multi-server mode as described below.</para>
<itemizedlist>
<listitem>
<para>If you have only a single OpenAM server, skip this step. OpenAM
enforces the session quota you set for the server.</para>
</listitem>
<listitem>
<para>If you have multiple servers with session failover configured, then
also skip this step. In this case OpenAM uses the session store to enforce
session quotas globally across your deployment. In other words when the
Set Active User Sessions is 5, a user can have a maximum of 5 active
sessions.</para>
</listitem>
<listitem>
<para>If you have multiple OpenAM servers but session failover is not
configured, configure multi-server mode for session quotas. Browse to
Configuration &gt; Servers and Sites &gt; Default Server Settings or
Configuration &gt; Servers and Sites &gt; <replaceable>Server
Name</replaceable>, and then use the Advanced tab page to set the
following advanced server property.</para>
<literallayout>openam.session.useLocalSessionsInMultiServerMode = true</literallayout>
<para>When you set this property to <literal>true</literal> for your OpenAM
servers, users can potentially reach the session quota for each individual
server before all session quotas are exhausted. In other words if you have
4 OpenAM servers and Set Active User Sessions is 5, then the user can have
a maximum of 20 (5 * 4) sessions.</para>
</listitem>
</itemizedlist>
</step>
</procedure>
</section>
</chapter>