Getting Started with Oracle Access Management

2.1 Starting and Stopping Servers in Your Deployment

The Oracle Access Management Console is deployed on the WebLogic Administration Server (AdminServer). Therefore, Oracle Access Management Administrators can access it only when the AdminServer is running. If the Oracle Access Management Console is protected by a WebGate, the OAM Server must also be running and the node Manager must be started before the other servers.

The following sections have more details:

2.1.1 Starting Node Manager

You can use the Node Manager, a Java utility, to perform common operations tasks for a Managed Server, regardless of its location with respect to its Administration Server. Node Manager must run before you can start and stop the WebLogic AdminServer, or WebLogic managed servers hosting OAM Servers.

After you complete the configuration, you need to make sure that the Node Manager runs the startNodeManager.sh script. Oracle WebLogic Administration Server does not do this automatically.

$WLS_HOME/server/bin/startNodeManager.sh

See the Oracle WebLogic Server Administrator Guide.

To start Node Manager:

Change to your $WLS_HOME/server/bin directory.
Enable Start Scripts: Run setNMProps to start the stack and instruct Node Manager to enable the use of start scripts (StartScriptEnabled=true).
```
./setNMProps.sh 
```
Start Node Manager.
```
./startNodeManager.sh
```

2.1.2 Removing OAM Server from WLS 12c defaultCoherenceCluster

Exclude all OAM clusters (including policy manager and OAM runtime server) from the default WebLogic Server 12c coherence cluster using the WebLogic Server Administration Console.

In OAM 12.2.1.3.0, server-side session management uses database and does not require coherence cluster to be established. In some environments, warnings and errors are observed due to default coherence cluster initialized by WebLogic. To avoid or fix these errors, exclude all OAM clusters from default WLS coherence cluster using the following procedure.

Login to the WebLogic Server Administration Console.
In the left pane of the console, expand Environment and select Coherence Clusters.
The Summary of Coherence Clusters page displays the Coherence cluster configurations that have been created in this domain.
Click defaultCoherenceCluster and select the Members tab.
From Servers and Clusters, deselect all OAM clusters (including policy manager and OAM runtime server).
Click Save.

2.1.3 Starting and Stopping WebLogic AdminServer

Starting the WebLogic AdminServer the first time can take 12-15 minutes or more. This process must not be interrupted or terminated as policy data might be corrupted.

The following procedure describes starting and stopping the WebLogic AdminServer using the scripts located in your $DOMAIN_HOME/bin directory.

Unix: startWebLogic.sh or stopWebLogic.sh
Windows: startWebLogic.cmd or stopWebLogic.cmd

WARNING:

If startWebLogic.cmd (Windows) or startWebLogic.sh (Linux) is stopped for any reason (whether accidently or because of a system crash or reboot), policy data might be corrupted. This would require removal and recreation of the domain and running the RCU again to recreate the OAM schema.

To start and stop WebLogic AdminServer:

Navigate to your $DOMAIN_HOME/bin.
Start AdminServer:
- Unix: ./startWebLogic.sh
- Windows: run startWebLogic.cmd
Stop AdminServer:
- Unix: ./stopWebLogic.sh
- Windows: run stopWebLogic.cmd

2.1.4 Starting and Stopping Managed WebLogic Servers and Access Manager Servers

You can perform all start and stop operations for managed WebLogic Servers hosting Oracle Access Management Servers (OAM Servers) from either a command prompt, the Oracle WebLogic Server Administration Console, the OAM Policy Manager Console, or the Oracle Enterprise Manager Fusion Middleware Control.

When using the command line scripts (located in the $DOMAIN_HOME/bin directory), the Managed Server name and the AdminServer URL are required as input.

The Unix system scripts are startManagedWebLogic.sh and stopManagedWebLogic.sh, and the Windows system scripts are startManagedWebLogic.cmd and stopManagedWebLogic.cmd.

To start and stop Managed WebLogic servers and Access Manager servers:

Navigate to $DOMAIN_HOME/bin.
Start OAM Server:
- Unix: ./startManagedWebLogic.sh MANAGED_SERVER_NAME ADMIN_SERVER_URL
- Windows: run startManagedWebLogic.cmd MANAGED_SERVER_NAME ADMIN_SERVER_URL
If the managed server is named oam_server1 and the AdminServer URL is http://examplewlsadminhost.example.com:7001, the start command run on a Unix system would be:
```
startManagedWebLogic.sh oam_server1 http://examplewlsadminhost.example.com:7001
```
Stop OAM Server:
- Unix: ./stopManagedWebLogic.sh MANAGED_SERVER_NAME ADMIN_SERVER_URL
- Windows: run stopManagedWebLogic.cmd MANAGED_SERVER_NAME ADMIN_SERVER_URL
If the managed server is named oam_server1 and the AdminServer URL is http://examplewlsadminhost.example.com:7001, the stop command run on a Unix system would be:
```
stopManagedWebLogic.sh oam_server1 http://examplewlsadminhost.example.com:7001
```

2.2 About Oracle Access Management Administrators

A single default LDAP group, the WebLogic Server Administrators group, is set in the Default User Identity Store (Embedded LDAP) designated as the System Store. The LDAP group, when assigned to a specified user, grants full system and policy configuration privileges.

Specifying a different LDAP group prohibits WebLogic Administrators from logging in to Oracle Access Management Console or from using administrative command-line tools.

Note:

Unless explicitly stated, the term Administrator in this guide refers to the Oracle Access Management System Administrator.

During initial deployment with the Oracle Fusion Middleware Configuration Wizard, the System Administrator userID and password are set. These credentials grant access to the:

Oracle Access Management Console to register and manage system configurations, security elements, and policies.

See Oracle Access Management Console and the Policy Manager Console for details.
WebLogic Server Administration Console to view the Summary of Server Configuration (Cluster, Machine, State, Health, and Listening Port) of deployed OAM Servers within the WebLogic Server domain, and also to Start, Resume, Suspend, Shutdown, or Restart SSL on these servers. See the Administering Oracle Fusion Middleware for more information.
Custom Administrative command-line tools (including the WebLogic Scripting Tool and Remote Registration Tool) provide an alternative to the Oracle Access Management Console for a specific set of functions.

See Command-Line Tools for Configuration.

Initially, a System Administrator user must log in to the Oracle Access Management Console using the WebLogic Administrator credentials set during initial configuration. However, your enterprise might require independent sets of Administrators: one set of users responsible for Oracle Access Management administration and a different set for WebLogic administration.

See Understanding Administrator Roles.

2.3 Oracle Access Management Console and the Policy Manager Console

Oracle Access Management allows for two console interfaces: Oracle Access Management Console, the full-featured graphical interface deployed on the WebLogic AdminServer and Policy Manager Console, the interface that can be deployed on one or more WebLogic Managed Servers.

Oracle Access Management Console: The Oracle Access Management Console can be accessed at:
```
http://wlsadminhost.example.com:7001/oamconsole
```
See Understanding the Oracle Access Management Console.
Policy Manager Console: It does not contain the full functionality available in the Oracle Access Management Console deployed on the AdminServer. The Policy Manager Console has only the policy administration functionality of the familiar Oracle Access Management Console. It is deployed when more capacity is needed to support many delegated administrative users of Access Manager policies.
```
http://wlsadminhost.example.com:14150/access
```

Note:

REST endpoints, WLST and the RREG servlet are available only on AdminServer.

2.4 Understanding the Oracle Access Management Console

The Oracle Access Management Console is a Web-based program that provides function controls for system and policy configuration.

This console displays a Launch Pad and subsequent pages based on the Administration Role to which a user is assigned a successful login. It is divided into Launch Pads and page-level tabs with forms and controls.

Note:

Admin operations are not supported on OAM console when DB is down. See Table 16-2

Any clicked shortcut appears as a named tab next to the Launch Pad. Each page is displayed only once. No warning is issued if you attempt to open the same page multiple times. The tab of the active page is white. Only the active page is visible and generally provides a work space where you can add, view, or modify related settings. Up to ten pages (tabs) can be open simultaneously. You can see named tabs for each page and click the tab to access a page that is concealed. See the following sections for details on the new Launch Pads.

Note:

The Oracle Access Management Console is designed for optimal display at a resolution of 1024x768.

2.4.1 System Launch Pad

The System Launch Pad will display when the user name of the Oracle Access Management System Administrator is entered.

See About Oracle Access Management Administrators.

This role has access to all functions and features of the Console including policy creation, system configuration, and services settings (including Access Manager, Security Token Service, Identity Federation, Access Portal, and so on).

When the System Administrator is logged in, access is granted to five Launch Pads:

Application Security contains the functions generally associated with Oracle Access Manager and single sign-on (SSO). From this Launch Pad, click the appropriate link to gain access to agent registration, policy and policy objects creation, session management, password policy, authentication modules, and plug-ins.
Federation contains functions associated with Identity Federation (including links to configure and manage Identity, and Service Providers), the Security Token Service, Social Identity, OAuth Services and the Access Portal Service.

Note:

Some of these services are disabled by default and would need to be enabled under the Configuration Launch Pad.
Configuration contains panels for managing the Oracle Access Management system settings. This includes enabling and disabling available Access services, configuring user identity stores and settings, certificate validation, server instances, and granting administrative permissions.

Figure 2-1 shows the Oracle Access Management System Administrator Console with the Application Security Launch Pad displayed. This is the default login view. Note the fours disabled tabs on the top right of the screenshot which, when clicked, will display the other Launch Pads visible by the System Administrator.

Figure 2-1 Oracle Access Management Administrator Launch Pad

Description of "Figure 2-1 Oracle Access Management Administrator Launch Pad"

2.4.2 Access Manager Launch Pad

The Oracle Access Manager Launch Pad and subsequent functionality are displayed when the user name entered is assigned to the Application Administrator (appadminuser) Role.

See Understanding Administrator Roles.

This role has access to all functions and features of the Console that includes policy object creation and policy management. When the Application Administrator is logged in, access is to the Launch Pads is limited to Access Manager and Automated Policy Synchronization (APS).

2.4.3 Agents Launch Pad

The Agents Launch Pad and the subsequent functionality are displayed when the user name entered is assigned to the Oracle Access Management Agent Administrator Role.

See Understanding Administrator Roles.

This role has access to all functions and features of the Console that include management and configuration of SSO Agents.

2.4.4 Help Desk Launch Pad

The Help Desk Launch Pad and the subsequent functionality are displayed when the user name entered is assigned to the Oracle Access Management Help Desk Administrator Role.

See Understanding Administrator Roles.

Users with this role lands on the http://wlsadminhost.example.com:7001/oamconsole/faces/helpdesk.jspx page after logging in. The System Administrator can access this console directly by entering the URL in the browser. Any one without the Help Desk Administrator role cannot access this page.

2.5 About Logging Into the Oracle Access Management Console

When accessing the Oracle Access Management Console, the WebLogic Server (AdminServer) host and port must be specified in the URL.

Let's assume the following sample URL, https://wlsadminhost.example.com:7001/oamconsole. In this URL, the following is true.

HTTPS represents the Hypertext Transfer Protocol (HTTP) with the Secure Socket Layer (SSL) enabled to encrypt and decrypt user page requests and the pages returned by the Web server
wlsadminhost.example.com refers to fully-qualified domain name of the computer hosting the Oracle Access Management Console (AdminServer)
7001 refers to the designated bind port for the Oracle Access Management Console, which is the same as the bind port used for AdminServer (the WebLogic Server Administration Console)
/oamconsole/ refers to the Oracle Access Management Console Log In page

Note:

If you specify an OAM Server host and port (as you would to access the ODSM console), the AdminServer redirects to the managed server which produces a ‘404 Not Found’ error.

When navigating to the /oamconsole URL, the default Oracle Access Management Console login page is displayed. The following sections have details on logging into the Oracle Access Management Console.

Note:

Ensure that you use the correct administrative credential to log in. Initially, the LDAP group for the Oracle Access Management Console Administrator is the same as the LDAP group defined for the WebLogic Server Administration Console (Administrators) and the common Default System User Identity Store store is the WebLogic Embedded LDAP.

2.5.1 Logging Into The Oracle Access Management Console

With appropriate administrative credentials, you can log into the Oracle Access Management Console.

Use this procedure to log in to the Oracle Access Management Console.

In a browser window, enter the URL to the Oracle Access Management Console using the appropriate protocol (HTTP or HTTPS). For example:
```
     https://hostname:admin_server_port/oamconsole/
```
On the Log In page, enter the Oracle Access Management Console Administrator credentials. For example:

Username: Admin_login_id

Password: Admin_password

Language: English

See Choosing a User Login Language.
Click the Login button.
- Successful: The Oracle Access Management Console Welcome page is displayed.
- Not Successful:
  
  See Administrator Lockout.
  
  See Also:
  
  About Oracle Access Management Administrators.

2.5.2 Logging Into the Secure Oracle Access Management Console (HTTPS)

After enabling SSL on the Adminserver and OAM Managed Server, or after configuring administration port (HTTPS), you can add the CA cert to the libOVD keystore. This allows logging in without connection issues.

To go into the Secure Oracle Access Management Console (HTTPS):

Change to the directory that contains the DemoIdentity.jks.

$ cd $MIDDLEWARE_HOME/wlserver_10.3/server/lib/
Export the CA certificate from the Weblogic keystore using the following commands.
The -list command prints the contents of the keystore for reference. DemoIdentityKeyStorePassPhrase is the default password for the keystore DemoIdentity.jks.
```
$ keytool -list -keystore DemoIdentity.jks 
  -storepass DemoIdentityKeyStorePassPhrase

$ keytool -exportcert -keystore DemoIdentity.jks 
  -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity 
  -file  ~/demoidentity.cer
```

Import the Weblogic CA certificate to the libOVD keystore.

cd $DOMAIN_HOME/config/fmwconfig/ovd/default 

mkdir keystores

cd keystores

$ keytool -importcert -keystore adapters.jks -storepass New_Password 
 -alias demoidentity -file ~/demoidentity.cer

Print the contents of the keystore to verify the import.

$ keytool -list -keystore ./adapters.jks -storepass New_Password

Add the password for the imported keystore to trustStorePassword in the server.os_xml file.

vim server.os_xml
server.os_xml: <keystore>keystores/adapters.jks</keystore>
server.os_xml: <trustStore>keystores/adapters.jks</trustStore>

<trustStore>keystores/adapters.jks</trustStore>
<trustStorePassword>New_Password</trustStorePassword>

Change the value of ADMIN_URL in startManagedServer.sh to point to the SSL port of the Weblogic server.
Restart both Adminserver and OAM Managed Server.
Log in as documented in Logging Into The Oracle Access Management Console.

2.6 Using the Oracle Access Management Console

Log on to the Oracle Access Managemet console to perform the common console functionality like accessing SSO Agent search page to search specific elements, accessing online help, and logging out of Oracle Access Management console.

The following topics describe common console functionality:

2.6.1 Logging Out of the Oracle Access Management Console

The Sign Out link appears in the upper-right corner of the Oracle Access Management Console. Click the Sign Out link to conclude your session. Oracle recommends that you also close the browser window after signing out.

To sign out of the Oracle Access Management Console:

Expand the drop down list under the name of the user that is logged in and select Sign Out.
Close the browser window.

2.6.2 Accessing Online Help in the Oracle Access Management Console

At any time while using the Oracle Access Management Console, you can click the Help link located in the drop down menu under the user name at the top of the Launch Pad page to get more information. Online Help topics link to information in an online version of this book. Generally, topics that are displayed by selecting Help in the Oracle Access Management Console appear in only English and Japanese languages. Online Help is not translated into the ADMIN languages.

You can click the Welcome tab to display a list of topics that describe actions you can take. For specific help topics, use the following procedure.

To access online help in the Oracle Access Management Console:

From the Oracle Access Management Console, click a tab.
Click Help in the drop down menu under the user name in the upper-right corner.
Review the page that appears in a new window and select one of the following links:
- More—Click this link to view more information.
- How?—Click this link to see steps to perform a task related to your help search.
- Contents—Expand Contents in the left Help pane to see all the help topics and the topics in the online manual.
- Search—Click this link to enter your search criteria in the help search window.
Click the following buttons, as needed:
- View—Displays a set of viewing options.
- Arrows—Return to the previous page or go forward to the next page.
- Printer Icon—Prints the page.
- Envelope Icon—Sends the page through email.

2.6.3 SSO Agent Search Page

The Oracle Access Management Console provides search controls for specific elements such as Agents, Application Domains, and Resources.

Figure 2-2 is a screen shot of a Search page used for SSO Agent searches.

Figure 2-2 SSO Agent Search Page

Description of "Figure 2-2 SSO Agent Search Page"

Search pages differ depending on the entity you are trying to find. In all searches, you can leave a field blank to display everything or use a wildcard (*) character if you do not know the exact name you seek. Some search controls include the ability to save your search criteria. From the search results table, you can choose an item to open for viewing or editing.

Note:

The search tool is case insensitive.

2.7 Command-Line Tools for Configuration

Several command-line tools are available to perform various tasks using the keyboard rather than the Oracle Access Management Console.

After using these commands, the configurations will be available in the console.

Remote registration tool, oamreg, enables remote registration of Agents, and creation of default Application Domains.

See Also:

OAM Agent Registration Parameters in the Console.
Oracle WebLogic Scripting Tool (WLST) provides a number of custom OAM command-line alternatives for tasks you can perform in the Oracle Access Management Console.

See Also:

Customization Commands in the WLST Command Reference for WebLogic Server.

2.8 Logging, Auditing, Reporting, and Monitoring Performance

Logging is the mechanism by which components and services write messages to a log file to capture critical component events, process, and state information. Auditing refers to the process of collecting for review specific information related to administrative, authentication, and run-time events. Access Manager provides a restricted-use license for Oracle BI Publisher and easy-to-use reporting packages. Monitoring performance refers to observing (viewing) performance metrics to make yourself aware of the state specific components.

Logging is the mechanism by which components write messages to a file. These messages can be logged at different levels of granularity. Oracle Access Management components use the same logging infrastructure and guidelines as any other component in Oracle Fusion Middleware 12c. Administrators can monitor performance and log messages for Access Manager using Oracle Fusion Middleware Control.

In Oracle Fusion Middleware, auditing provides a measure of accountability and answers to the “who has done what and when" types of questions. Oracle Access Management uses the Oracle Fusion Middleware Common Audit Framework to support auditing for a large number of user authentication and authorization run-time events, and administrative events (changes to the system). The Oracle Fusion Middleware Common Audit Framework provides uniform logging and exception handling and diagnostics for all audit events.

2.9 Configuring Oracle Access Management Login Options

Oracle Access Management allows you to configure user login options like choosing a user login language, configuring forgot password URL, and many more.

The following topics describe how to configure Oracle Access Management user login options:

2.9.1 Administering the Forgot Password URL

When a user clicks the Forgot Password link on the Oracle Access Management login page, the user is taken to an Oracle Access Management Forgot Password page where a new password can be set in the case of a forgotten one.

The following sections contain procedures for administering the Forgot Password URL.

2.9.1.1 Setting a Forgot Password URL

You can set a new Forgot Password URL.

Run the following command:

curl  --user weblogic:password  
     -w  "%{http_code}"   
     -i  -H 
     "Content-Type:application/json"   
     -H "Accept: */*"   
     -X PUT   -d
       '{"forgotPasswordURL":"http://oam-host:7777/identity/faces/forgotpassword"}' 

http://host:7001/oam/admin/api/v1/configurationService/forgotPassword

If successful, the “Forgot Password URL configured successfully" message is displayed in the output. If there is already a URL set for Forgot Password, running the command overwrites the previous Forgot Password URL.

2.9.1.2 Retrieving a Forgot Password URL

You can retrieve the Forgot Password URL.

Run the following command:

curl --user weblogic:password
     -w “%{http_code}" \
     -i \

   http://host:7001/oam/admin/api/v1/configurationService/forgotPassword

2.9.2 Choosing a User Login Language

Topics relevant to user language selection in OAM include:

2.9.2.1 User Login Language Code

Oracle Access Management supports language selection through a drop down list of languages on the login form combined with use of the OAM_LANG_PREF language preference cookie.

Table 2-1 lists the supported languages and applicable language codes.

The Language column refers to languages supported by the Login Pages and the Administrators column refers to languages supported by the Oracle Access Management Console. If the language is supported by the Login Page, simply change the browser's language and users should see a translated page.

Table 2-1 Language Codes For Login Pages

Language Code	Language	Administrators
ar	Arabic
cs	Czech
da	Danish
de	German	German
el	Greek
en	English	English
es	Spanish	Spanish
fi	Finnish
fr	French	French
fr-CA	Canadian French
he	Hebrew
hr	Croatian
hu	Hungarian
it	Italian	Italian
ja	Japanese	Japanese
ko	Korean	Korean
nl	Dutch
no	Norwegian
pl	Polish
pt-BR	Brazilian Portuguese	Brazilian Portuguese
pt	Portuguese
ro	Romanian
ru	Russian
sk	Slovak
sv	Swedish
th	Thai
tr	Turkish
zh-CN	Simplified Chinese	Simplified Chinese
zh-TW	Traditional Chinese	Traditional Chinese

To accomplish a very specific login experience, implement a custom login page using the customization facilities in Oracle Access Management as described in Developing Applications with Oracle Access Management.

2.9.2.2 Selecting A Language for Oracle Access Management Login

Oracle Access Management provides the language selection methods.

Table 2-2The order of these items in the table illustrate the preference order.

You can use the configOAMLoginPagePref WebLogic Scripting Tool (WLST) command to configure the login page language preferences.

See the WebLogic Scripting Tool Command Reference for Identity and Access Management for information regarding this WLST command.

Table 2-2 Oracle Access Management Language Selection Methods

Method	Description
Server Override	Allows the OAM Server to determine the language. It is intended to support scenarios where the User Agent cannot reliably indicate its language preference(s) or where the administrator needs to override other selection mechanisms for operational reasons.
Preference Cookie	A domain cookie (similar to ORA_FUSION_PREFS) that contains the user's language preferences. It is intended to allow lang preferences maintained by an application(s) personalization facilities to be used. Note: Multiple DNS domain support for the Preference Cookie is a limitation today. The solution will include Resource Webgates using the OAM Front-Channel protocol in combination with local resource cookie enhancements to manage preference cookie semantics across DNS domains. See Also: "Language Preference Cookie"
Browser Language	Allows User Agents (Browsers, REST Clients, HTTP Clients) to specify the user's language preference via an HTTP Accept-Language header.
Default Language	Used if Oracle Access Management cannot determine the user's language preference based on the specified selection mechanisms.

Language preferences are disabled until explicitly enabled. By default, the login form does not include the list of language values until the application locales are specified.

Note:

Language Selection is only available in the ECC login page; it is not currently available in the DCC login page.

2.9.2.3 Language Preference Cookie

The language preference cookie, OAM_LANG_PREF is a domain scoped cookieas described in Table 2-3.

Table 2-3 OAM_LANG_PREF Cookie

Parameters	Description
Name	OAM_LANG_PREF
Domain	Domain-scoped cookie
Path	/
Value	[Cookie version] [separator] [UTF-8 BASE64(name-value pairs)] For example: v1.0~kqhkiG9w0BAQQFADCB0TELM
ExpirationTime	Persistent \| Session (default) – Specified in OAM configuration
Secure Flag	Yes
preferredLanguage	BCP47/RFC4647. Specifically, the value space should conform to what is formally called the "language priority list".
defaultLanguageMarker	true (reconcile cookie with application maintained preferences) \|false (read from cookie).
Cookie Lifecycle	Oracle Access Management and other applications can perform create, read, update, and delete operations.

2.9.2.4 Propagating Language Preference and Application Integration

Oracle Access Management will propagate the language selected by the user to applications.

For more details, see Table 2-4.

Table 2-4 Application Integration for Language Preference

Method	Description
HTTP Accept-Language Header	This enables application to integration without code change. This is a major advantage over the other options. We can expect this to be good for most applications that respond to the browser locale setting. This is the standard practice in internationalizing a Web application. We expect this to be able to become the standard option for all ADF based products, as well as any application that responds to browser locale. Note: OAM Agents ensure that the Accept-Language reflects the language selected. Also, ServletFilters could be used to make this happen.
Access Manager Policy Response	Access Manager stores the language selection in the attribute langPref in the session namespace. For instance: `$session.langPref`. This attribute can be passed to downstream applications using an HTTP Header and/or Cookie through the Access Manager Policy Response. The name of the Header and/or Cookie is a deployment time assignment.
Preference Cookie	When the language selected during login differs from the value stored in the Preference Cookie, Oracle Access Management will update the "`preferredLanaguage`" parameter in the Preference Cookie with the newly selected language and set the defaultLanguageMarker" parameter to "`false`".
IdentityContext	The language preference can be propagated as a custom claim in the IdentityContext. Select "oracle:idm:claims:session:attributes" as the claim name and then specify the session attribute using the following notation: "`preferredLanguage=$session.langPref`. The claim will be created with the name of "`oracle:idm:claims:session:attributes:preferredLanguage`" and value equal to the session's `langPref` attribute.

2.9.3 Understanding Persistent Login

With Access Manager, a user needs to re-authenticate after a period of session inactivity defined by the Idle Timeout parameter (default is 15 minutes) and once the session expires, due to the value of the Session Lifetime parameter (default is 8 hours). The Persistent Login functionality offers administrators the option to skip user re-authentication for a considerably longer period of time should the user opt in - allowing a user two weeks or a month significantly improves convenience. Persistent Login (sometimes referred to as Remember Me or Keep Me Signed In) can be enabled or disabled with the period of time being configurable. It is disabled by default.

Persistent Login is enabled in the oam-config.xml global configuration file. The appropriate Application Domain must also explicitly allow Persistent Login. When enabled globally, the user login page will have a Keep Me Signed In checkbox and, when checked, the user receives an RMToken. Once the user's session expires or times out, a user with an RMToken will not be challenged if the resource is in the Application Domain that allows Persistent Login and if its authentication level is adequate. If the user tries to access a resource in an Application Domain that has not opted in, the user will be challenged for credentials even if the authentication level is adequate. (If the user does not opt in when logging in, reauthentication will be prompted after a session expiration or inactive timeout.)

Note:

If the Application Domain 'Session Idle Timeout' is specified, Persistent Login cannot be enabled.

The following behaviors are pertinent to the Persistent Login functionality.

If enabled for the user logged in to Access Manager from a device browser, closing and reopening the browser does not require reauthentication within the defined Persistent Login time period
Session activities will be reflected in the Audit data.
When the time period expires, the end user is asked to authenticate again.
When attempting to access applications from a different device (or even a different process/browser in the same device), the end user will be asked to authenticate again.
When the user clicks log out, the OAM_RM token is deleted and they user must log in again. Session termination by an administrator will have the same effect.
As the OAM_RM token is based on credentials entered at the time of token creation, any event that changes the password status will invalidate the token and force the user to re-authenticate. This includes:
- Password expiration
- Password reset by administrator
- Password changed by the user on a different device
- User deleted or locked by the administrator
To address a stolen device scenario, the administrator can terminate all sessions for all devices/browsers of a user. The user will need to re-authenticate but has the option to enable Persistent Login on the login page
Application triggered re-authentication forces the user to re-authenticate even if Persistent Login is enabled as the application is intentionally challenging the user before doing a sensitive operation.
When a user navigates from an application which allows Persistent Login to one that does not, although the user is logged in automatically, the application which does not allow Persistent Login will challenge the user to enter credentials.
Persistent Login is not available in application triggered login pages.

The following topics provide additional details:

2.9.3.1 Enabling Persistent Login

The feature is not enabled by default.

To enable Persistent Login globally:

Connect to WebLogic Server using connect().

Provide the username and password when prompted.
Run the command:

configurePersistentLogin(enable="true", validityInDays="30", maxAuthnLevel="2", userAttribute="obPSFTID")

Create a new Authentication Scheme for Persistent Login using the values in the following table.

See Managing Authentication Schemes.

The 'Keep me signed in' check box will be displayed only when accessing a resource protected by this scheme.

Attribute	Value
Name	PersistentLoginScheme (or any name)
Description	any description
Authentication Level	2
Challenge Method	FORM
Challenge Redirect URL	/oam/server/
Authentication Module	LDAPPlugin
Challenge URL	/pages/login.jsp
Context Type	default
Context Value	/oam
Challenge Parameters	enablePersistentLogin=true

Click the Application Domains link in the Launch Pad.
Click the Application Domain for which you will use this PersistentLoginScheme and change its Authentication Scheme as documented in this sub procedure.

See Defining Authentication Policies for Specific Resources.
1. Click the Authentication Policies tab in the appropriate Application Domain.
2. Change the Authentication Scheme for the Protected Resource Policy to PersistentLoginScheme. This allows persistent login for this policy.
  
  Note:
  
  The Public Resource Policy should not be modified.

Click the Application Domain under which you will create a Response for all configured Authorization Policies as documented in this sub procedure.

There may be multiple authorization policies and this needs to be done for all.

See About Constructing a Policy Response for SSO.

Click the Authorization Policies tab in the appropriate Application Domain.
One at a time, click an Authorization Policy in this Application Domain to open its configuration tab.
Click Responses.
Click Add to create an Authorization Response in the Application Domain.

Enter the following values in the displayed Add Response pop-up and click Add.

Attribute	Value
Type	Session
Name	allowPersistentLogin
Value	true NOTE: To disable Persistent Login for an Application Domain you must disable Authorization Responses by changing the value of the Value attribute in the Add Response pop-up to false.

Attribute

Value

Type

Session

Name

allowPersistentLogin

Value

true

NOTE: To disable Persistent Login for an Application Domain you must disable Authorization Responses by changing the value of the Value attribute in the Add Response pop-up to false.

Go to “Conditions” tab.
Click Add. Provide Name=TRUE, Type=TRUE.
Click Add Selected.
Go to “Rules” tab.
In the “Allow Rule” section move the condition TRUE (true) from “Available Conditions” to “Selected Conditions” section.
Click Apply.

Perform this procedure for all Authorization Policies before moving on to the next step.

Access a resource protected by this scheme.

The 'Keep me signed in' checkbox is displayed on the login page.
Provide valid credentials and select 'Keep me signed in'.
Close and re-open the browser.
Access the same resource.

You will be logged in automatically without asking for credentials.

Note:

Persistent Login can also be enabled and disabled using WLST. See the WebLogic Scripting Tool Command Reference for Identity and Access Management for details on the configurePersistentLogin command.

2.9.3.2 Troubleshooting Persistent Login

When enabling Persistent Login using WLST, an LDAP attribute named obpsftid is defined to store the Persistent Login properties. When the user is locked, the obpsftid attribute needs to be updated but the oamSoftwareUser does not have sufficient LDAP rights over it.

To give oamSoftwareUser permission:

Copy the LDIF data below and paste it into a file that you will save as oam_user_write_acl_users_obpsftid_template.ldif.

##############################################################################
# Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. 
#
# NAME: idm_idstore_groups_acl_template.ldif
#
#
# DESCRIPTION:
#
# This file provides appropriate ACLs to user and group containers.
#
#
# SUBSTITUTION VARIABLES:
#
# %s_UsersContainerDN%  : The container in which users reside  
# %s_GroupsContainerDN% : The container in which groups reside
#
##############################################################################
dn: %s_UsersContainerDN%
changetype: modify
delete: orclaci
orclaci: access to attr=(obUserAccountControl, obLoginTryCount, obLockoutTime, oblastsuccessfullogin, oblastfailedlogin, obpasswordexpirydate, obver, obLastLoginAttemptDate, oblockedon) by group="cn=orclFAOAMUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write) by group="cn=orclFAUserReadPrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare) by group="cn=orclFAUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write)
-
add: orclaci
orclaci: access to attr=(obUserAccountControl, obLoginTryCount, obLockoutTime, oblastsuccessfullogin, oblastfailedlogin, obpasswordexpirydate, obver, obLastLoginAttemptDate, oblockedon, obpsftid) by group="cn=orclFAOAMUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write) by group="cn=orclFAUserReadPrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare) by group="cn=orclFAUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write)

Do the following in the created oam_user_write_acl_users_obpsftid_template.ldif.
- Replace %s_UsersContainerDN% with User Search Base.
- Replace %s_GroupsContainerDN% with Group Search Base.

Change to the OID directory and run ldapmodify.

$ setenv ORACLE_HOME <OID_INSTALL_LOCATION>
$ cd $ORACLE_HOME/bin
$ ./ldapmodify -h <LDAP server> -p <LDAP port> -D <bind DN> -w <bindpassword> 
 -v -f oam_user_write_acl_users_obpsftid_template.ldif