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:
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.
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.
Topics relevant to user language selection in OAM include:
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 inOracle Fusion Middleware Developer's Guide for Oracle Access Management.
Note:
Prior to the release of 11.1.2.1, 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 11.1.2.1 model.
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.
Note:
Language Selection is only available in the ECC login page; it is not currently available in the DCC login page.
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. |
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: 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 " |
|
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: " The claim will be created with the name of " |
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:
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.
Click the Authentication Policies tab in the appropriate Application Domain.
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. |
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 WLST Command Reference for WebLogic Server for details on the configurePersistentLogin command.
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: