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. 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 
     -H "Accept: */*"   
     -X PUT   -d


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. Retrieving a Forgot Password URL

You can retrieve the Forgot Password URL.

Run the following command:

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


2.9.2 Choosing a User Login Language

Topics relevant to user language selection in OAM include: 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





























Canadian French






























Brazilian Portuguese

Brazilian Portuguese























Simplified Chinese

Simplified Chinese


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 inOracle Fusion Middleware Developer's Guide for Oracle Access Management.


Prior to the release of, Oracle Access Manager relied on the Browser Language preference (Accept-Language HTTP Header) to determine the language in which the login page was rendered. The default, if the language could not determined, was English (en-us). This behavior is supported going forward until existing applications have migrated to the model. 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 theWLST Command Reference for WebLogic Server 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.


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

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

Table 2-3 OAM_LANG_PREF Cookie

Parameters Description




Domain-scoped cookie




[Cookie version] [separator] [UTF-8 BASE64(name-value pairs)]

For example:



Persistent | Session (default) – Specified in OAM configuration

Secure Flag



BCP47/RFC4647. Specifically, the value space should conform to what is formally called the "language priority list".


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. 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".


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.)


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: Enabling Persistent Login

The feature is not enabled by default.

To enable Persistent Login globally:

  1. Connect to WebLogic Server using connect().

    Provide the username and password when prompted.

  2. Run the command:

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

  3. 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


    PersistentLoginScheme (or any name)


    any description

    Authentication Level


    Challenge Method


    Challenge Redirect URL


    Authentication Module


    Challenge URL


    Context Type


    Context Value


    Challenge Parameters


  4. Click the Application Domains link in the Launch Pad.

  5. 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.


      The Public Resource Policy should not be modified.

  6. 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.

    1. Click the Authorization Policies tab in the appropriate Application Domain.

    2. One at a time, click an Authorization Policy in this Application Domain to open its configuration tab.

    3. Click Responses.

    4. Click Add to create an Authorization Response in the Application Domain.

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

      Attribute Value







      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.

      1. Go to “Conditions” tab.

      2. Click Add. Provide Name=TRUE, Type=TRUE.

      3. Click Add Selected.

      4. Go to “Rules” tab.

      5. In the “Allow Rule” section move the condition TRUE (true) from “Available Conditions” to “Selected Conditions” section.

      6. Click Apply.

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

  7. Access a resource protected by this scheme.

    The 'Keep me signed in' checkbox is displayed on the login page.

  8. Provide valid credentials and select 'Keep me signed in'.

  9. Close and re-open the browser.

  10. Access the same resource.

    You will be logged in automatically without asking for credentials. 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:

  1. 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
    # This file provides appropriate ACLs to user and group containers.
    # %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)
  2. 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.

  3. Change to the OID directory and run ldapmodify.
    $ 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