| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.2.0) Part Number B32419-01 |
|
|
View PDF |
| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.2.0) Part Number B32419-01 |
|
|
View PDF |
This chapter covers tasks that affect the basic functionality of Oracle Access Manager, including configuring multiple languages and directory and database server configuration.
This chapter also discusses how to control the appearance and functionality of Identity System applications. For example, through the searchbase and stylesheet, you may want to control what users can view or the actions they can perform in Identity System applications. You may want to add additional Identity Servers or WebPasses for better performance.
To help you manage these tasks, you can specify other Oracle Access Manager Administrators and Master Identity Administrators, as described in "Specifying Identity System Administrators".
This chapter contains the following topics:
Cloned and Synchronized Components
Note:
You must be a Master Administrator to configure the Identity System. Most tasks in this chapter are performed through the Identity System Console.See also "Changing Transport Security Modes", "Implementing .NET Features", "Logging", "Auditing", and "SNMP Monitoring".
You use styles to change the appearance or limit functionality across Identity System applications. A style is a named collection of stylesheets, graphics files, and scripts that define a certain user interface for the system. A style is based on stylesheets that define the appearance of elements in application pages, including the names of fields and functions, the GIF images used to specify the colors, shapes, and sizes of tabs and buttons, and the fonts used for tab and button names.
Styles can be cosmetic or functional. A cosmetic style determines the appearance of Identity System applications, such as color, or the appearance of tabs. A functional style determines the functionality of Identity System applications. That is, you can add, modify, or remove particular functions on an Identity System application page. For example, you can remove the Substitute Rights function from all three Identity System applications. The Identity System provides a default style named Classic Style but you can use PresentationXML to develop other styles to change the appearance of the Identity System.
You can use the Customize Styles option in the Identity System Console to set the default style, create styles, modify styles, or delete styles. However, when you create or modify a style through the Identity System Console, the system copies the existing stylesheet and renames it. You must then open the stylesheet and manually make the necessary changes.
See the information on designing the GUI with PresentationXML in the Oracle Access Manager Customization Guide for details about creating and modifying stylesheets.
Note:
You can change only the appearance of Identity System application pages. The System Console uses a style setting that cannot be modified.This section discusses the following topics:
You can use the following procedure to view currently configured styles. This leads to the Customize Styles page, which is the starting point for style-related procedures.
To view currently configured styles:
From the Identity System Console, select System Configuration.
In the left navigation pane of the System Configuration page, select Styles.
The Customize Styles page appears. The following example shows the Classic Style, which is the default provided by the Identity System.
Click the style's link to view a style's parameters.
You will see the style name, directory where style files are stored, and the source of those files (in the Copy from field).
The Identity System out-of-the-box provides one default presentation style, known as Classic Style. The IdentityServer_install_dir/identity/oblix/lang/en-us/style0 directory contains XSL wrapper stylesheet files for the Classic Style. Most of these files point to global shared stylesheet template files for all languages in the IdentityServer_install_dir/identity/oblix/lang/shared directory.
The process of creating a custom style for presentation of Identity System pages for user applications begins by adding a new style to the Identity System, as described here. The result is a new custom style directory with XSL wrapper stylesheet files. Then you may either copy and modify an existing style or create an entirely new style based on new stylesheets.
Note:
You may only change styles for user applications. The System Console always uses the default style.In either case, adding a style (and custom style directory) to the Identity System follows the same method: you provide a style name and a directory name for your style files. You may also choose an existing style on which to base your new style. After selecting your new style as the default, you can begin customizing copies of Identity System stylesheets or creating your own. To complete the process, you need to copy your new stylesheets and GIFs to all Identity Servers and WebPass machines, respectively.
Before adding your first new style, there are a few things to take into account:
Multiple Languages: To support multiple languages, the Identity System provides a specific named directory for each installed language. For example, /lang/en-us is the default English language directory, /lang/fr-fr is the French language, and so on. Both the Identity System default and your custom style directories are stored within each installed language directory.
Suppose you have a French Language Pack installed. In this case, both lang/en-us and lang/fr-fr directories include the /style0 directory. When you add a style to the Identity System, your new style directory is added in both the lang/en-us and lang/fr-fr directories:
IdentityServer_install_dir/identity/oblix/lang/en-us/NewStyle
IdentityServer_install_dir/identity/oblix/lang/en-us/style0
IdentityServer_install_dir/identity/oblix/lang/fr-fr/NewStyle
IdentityServer_install_dir/identity/oblix/lang/fr-fr/style0
Your Style Name: The Identity System uses the style name you supply internally. As a best practice, your style name should match your custom style directory name and should be easily recognizable. Do not include white spaces, &, *, or parentheses () in the name.
Your Style Directory Name: The directory name you specify will be used to create a directory for related wrapper stylesheet files. This name should match your style name and follows the same rules for naming.
In addition, your custom style directory name is also assigned to an XML document (a duplicate of style0.xml) that is created to identify the status and origin of your new style. For example, if your new directory is named Pastel, a file is created and stored as:
IdentityServer_install_dir/identity/oblix/config/style/Pastel.xml
No other files are created during this process. However, the styles.xml file will be updated to include a NameValPair specifying the directory and style name and directory name that you supply. For example:
IdentityServer_install_dir/identity/oblix/config/style/styles.xml
The style information files in the config/style are not included on WebPass. For more information, see the Oracle Access Manager Customization Guide.
Copy from an Existing Style: You may copy stylesheets from an existing style directory or select None to build a style that is not based on an existing style or to customize only selected stylesheets.
Note:
If this is the first style being added, the only available style is the default Classic Style.Selecting None: If you select None, the directory that is created is empty and you must manually create a set of stylesheets for your new style or selectively copy files from the /style0 directory to work with.
If you select None, your new style's status will appear as "Under Construction" within the Identity System until you select a style for it. An empty style directory is created automatically, and a duplicate of style0.xml is created in IdentityServer_install_dir/identity/oblix/config/style/style0.xml.
Selecting a Style: When you select a style to copy from, a duplicate of the directory you copied from is created under the custom directory name you specify. The copied files retain relative references to the directory you copied from (/style0 or a custom style that you chose to copy from).
During customization, you only change references that refer to the changed version of the stylesheet in the your new style directory.
Results: Suppose you added a new style named Pastel in a directory named Pastel and you copied from the default Classic Style. In this case, the Pastel directory is created in each langTag directory and populated with duplicate files from Classic Style's directory, /style0:
IdentityServer_install_dir/identity/oblix/lang/en-us/Pastel
The Classic Style directory, /style0, remains intact as:
IdentityServer_install_dir/identity/oblix/lang/en-us/style0
In addition, an XML document that duplicates style0.xml is created when the new style is selected as the default, named after the directory you created, and stored with style0.xml in config/style:
IdentityServer_install_dir/identity/oblix/config/style/Pastel.xml
IdentityServer_install_dir/identity/oblix/config/style/Pastel.xml.lck
For additional information and a look at the content of various files, see the Oracle Access Manager Customization Guide.
From the Identity System Console, select System Configuration, then select Styles to display the Customize Styles page.
Click the Add Style button to display the Add Style page.
Fill in the fields on the Add Style page, for example:
Name: Pastel
Directory Name: Pastel
Note:
The style name you specify here is used internally by the Identity System and should match the directory name you supply.In the Copy From field, select an existing style to use as a template for your new style.
For example:
Classic Style
Click Save to save the new style.
The new style name is listed in the Customize Styles page. One or more directories are created to hold the new wrapper stylesheets.
Select the new style as your default style, as follows:
Click the Setup Default Style button to display the Set Default Style page.
Click the Make Default button beside your new style name, then click Save.
Check your file system for the new style directory name you specified.
Next you customize styles. For details about customizing Identity System pages, copying styles, testing, and propogating styles, see the Oracle Access Manager Customization Guide.
The following procedure enables you to make a style available to end users:
Append the directory name containing the stylesheets to the URL of the first page where users enter the Identity System, as follows:
&style=directory_name
where directory_name is the name of the directory that contains the stylesheets for the Identity System.
For details about testing and propogating styles, see the Oracle Access Manager Customization Guide.
You can change the name of a style using the steps in the following procedure as a guide.
From the Identity System Console, select System Configuration, then select Styles to display the Customize Styles page.
In the Customize Styles page, click the name of the style that you want to rename.
The View Style page appears.
Click Modify.
The Modify Style page appears.
Change the style name.
Click Save to save your changes.
The View Style page displays the new style name.
You cannot modify Classic style, the default style provided by the Identity System, because it is used by the Identity System. However, you can modify any of the custom styles you have created.
Modify the corresponding stylesheets, as discussed in the chapter on designing the user interface with PresentationXML in the Oracle Access Manager Customization Guide.
When you have completed your changes, copy the stylesheets to each Identity Server and to each WebPass linked to the Identity Server where the stylesheets were modified.
You cannot delete the Classic Style, the default style provided by the Identity System, because it is used by the Identity System. However, you can delete any of the custom styles you have created.
In the Customize Styles page, click the name of a style.
The View Style page appears.
Click Delete.
When prompted, confirm your deletion.
The Customize Styles page reappears.
Delete the new stylesheets from the new style directory in all the other Identity Servers, as well as the WebPass installation area.
You use the Setup Default Style option to choose the default style for applications.
Note:
You cannot select a style that has the Under Construction status.In the Customize Styles page, click Setup Default style.
The Set Default Style page appears.
Click Make Default beside your choice.
Click Save.
In the Customize Styles page, the words "Available & Current Default" appear next to the style you selected.
As discussed in the Oracle Access Manager Installation Guide, the English language is installed automatically. However, you can install one or more Oracle-provided Language Packs. Language Packs enable you to provide localized information to end users and administrators in the languages identified in the Oracle Access Manager Introduction.
Some display names and attributes appear for end users in Identity System applications (User Manager, Group Manager, and Org. Manager), as well as in administrator applications (Identity System Console, Access System Console, and Policy Manager).
For end-users, Oracle Access Manager 10g (10.1.4.0.1) enables the display of static application data such as error messages, and display names for tabs, panels, and attributes in supported end -user languages. Administrative information can be displayed in only supported administrator languages.
After installation and setup, you must configure languages for use and localize attribute display names, which you can accomplish at the following levels:
Object Class level
Tab level
Panel level
Search Result Attributes level
Note:
Oracle recommends that you configure display names at the Object Class level because this is the highest level. If you choose to configure display names at a lower level, ensure that you provide display names at each level for all languages.Task overview: Configuring multi-language functionality
Install and set up Oracle Access Manager with one or more Oracle-provided Language Packs, as described in the Oracle Access Manager Installation Guide.
Enable the languages you have installed and want to use, as described in "Managing Multiple Languages" .
Configure the applications to use an installed language by manually entering the display names for labels and attributes. For example:
Localize object class attributes, as described in "Localizing Attribute Display Names".
Localize display names for tabs, group type panels, search result attributes, and reports, as described in "Configuring User, Group, and Organization Manager".
Localize workflow panel names, as described in "Localizing Workflow Panels".
Localize tab names to display them in other languages, as described in "Localizing Tabs".
Localize search result attributes, as described in "Viewing, Modifying, and Localizing Attributes that Appear in Search Results".
If you have installed and configured more than one language, you can determine the language to use for administrative information in the Identity and Access System Consoles, and Policy Manager. You do this from your browser. See your browser's documentation for details.
If administrative pages are requested in a language that is not supported for administrative information, the default language that was selected during product installation is used to display administrative pages.
After enabling installed languages, and configuring attributes to use the installed languages, the language used to display application pages to an end user is chosen according to the following evaluation order.
Evaluation Order
The language specified in the URL.
The user can specify a language in a URL. For instance, when a user selects the Create User function in the User Manager, he or she can append lang=fr-fr to display the User Manager page in French. The application first looks for a language preference specified in the URL for a resource. The user or the administrator can specify a language in the URL by appending lang=languageTag, where languageTag is a language tag in RFC 1766 format.
The following example returns the Create User Profile page in French:
http://localhost/identity/oblix/apps/userservcenter/bin/userservcenter.cgi? program=workflowCreateProfile&tab_id=employees&lang=fr-fr
The language stored in a parameter called LangCookie in the ObTEMC cookie.
Once you specify the language in a URL as in the previous step, this language is set in the LangCookie parameter. The ObTEMC cookie is created when the user logs in and is maintained for the duration of the user's session. If a URL does not contain the language specification, The application checks the ObTEMC cookie, which lasts for the duration of the session. The ObTEMC cookie can also be set on a form or a page.
The language specified in the HTTP header variable, HTTP_OBLIX_LANG.
You can create an authentication or authorization success header variable to contain this value, as explained in the chapters on authentication and authorization in Oracle Access Manager Access System Administration Guide. If you want to change the name of the HTTP_OBLIX_LANG header variable, you can do so in the following files:
IdentityServer_install_dir/oblix/apps/common/bin/globalparams.xml
PolicyManager_install_dir/access/oblix/apps/common/bin/globalparams.xml
where IdentityServer_install_dir is the directory where the Identity Server is installed, and PolicyManager_install_dir is where the Policy Manager is installed.
See the Oracle Access Manager Customization Guide for information on globalparams.xml.
The value set by the user's Web browser determines the default language. This value is specified in the header variable, Accept-Language.
If the application does not find the HTTP_OBLIX_LANG header variable, it looks for the Accept-Language header variable that is set in the user's browser.
Note:
Both the HTTP_OBLIX_LANG and the Accept-Language header variables are configurable. See the Oracle Access Manager Customization Guide for information.The default language of the Oracle Access Manager installation.
If the Accept-Language header variable is not found in the user's browser, the application looks in the obnls.xml configuration file for the default language of the Oracle Access Manager installation.
The obnls.xml file is located in the IdentityServer_install_dir/identity/oblix/config directory. IdentityServer_install_dir is the directory where the Identity Server is installed.
See "Managing Multiple Languages" for details.
Configuring an Identity Server includes specifying the duration of user sessions, specifying email addresses for user feedback, configuring mail servers for notification events, managing the cache, and enabling multiple languages.
You use the Identity System Console to view and modify server settings.
This section discusses the following topics:
To view or modify server settings
In the Identity System Console, select System Configuration, then select Server Settings.
The View Server Settings page appears, which looks something like the one in the following screen shot.
To view or modify a value for a setting, click the link for the setting (Mail Server or Multi-Language, for example).
Make the changes you want, if any.
Click Save to save your changes (or Cancel to exit without saving your changes).
Restart the Identity Server for the new values to take effect.
Configuring session timeout enables you to specify user-idle session time (in minutes). The user session automatically ends when the specified idle time elapses.
The setting in this page applies to all users and all Identity System applications. You cannot have different settings for different users and applications.
A session timeout does not apply if you are using a Web-server-based login, such as through a WebGate, because the WebGate instance handles the timeout.
Note:
Resources protected by Web single sign-on always ignore idle session timeout settings.To configure the length of a user's Identity System session
In the Identity System Console, select System Configuration, then select Server Settings, then click Configure session timeout to display this page.
Choose the timeout option:
No Timeout: User sessions continue indefinitely as long as the browser is active.
Idle Session Timeout: The number of minutes to wait before ending an idle session. After this period of inactivity elapses, the user must log in to the application to continue.
There are several reasons for ending an idle session after a predetermined time period. A short session protects users who leave their workstations without locking them, making them vulnerable to unauthorized use.
Refresh Period: Configures how often to update the user session time stamp. A value of 0 (zero) means the session time stamp is updated on every request. Oracle recommends you set this value to 1/4 of the Idle Session Timeout value.
Click Save to save your changes (or Cancel to exit the page without saving).
Use the Customize Email function to specify email addresses for user feedback. End users access these addresses by clicking About on the side navigation bar, then clicking Submit Admin Feedback or Submit Oracle Feedback.
To customize email destinations
In the Identity System Console, select System Configuration, Server Settings.
In the Server Settings page, click Customize Email Destinations to display this page.
Type email addresses for the following fields:
Email address for Bug Reports: You must change this address if you plan to send it to a person or alias in your organization. This person or department can either solve the problem or contact Oracle for help.
Email address for User Feedback: If users in your company cannot send email outside the local network, you can type an internal address in the Bugs and Feedback fields. Provide the address of a user who is responsible for forwarding the information to Oracle.
Webmaster's email address: Type the email address of the user in your company responsible for administering Oracle Access Manager.
Click Save to save your changes (or Cancel to exit the page without saving).
The Identity System can issue emails alerts during request ticket processing and group management, notification of password expiration, or modification of a Profile attribute. Use the SMTP server configuration function to configure how the Identity System handles these emails.
When configuring a mail server, one of your options is Supports MHTML email. MHTML stands for MIME encapsulation of aggregate documents, such as HTML.
MHTML lets you send an HTML document with in-line graphics, applets, and linked documents in a MIME multipart/related body format. You can provide links to other parts included in the HTML document by using the CID (content-ID) URLs or any other kind of URL. The linked body part is identified in its header by either a content-ID (linked to by CID URLs) or a content-location (linked to by any other kind of URL).
The main difference between HTML and MHTML is that with MHTML, graphics are in-line in the email instead of referenced with a link as in HTML format.
In Identity System Console, select System Configuration, then select Server Settings
In the Server Settings page, click Mail Server to display this page.
In the Server Name field, enter your SMTP server name.
In the Server Port Number field, type the mail server's port number.
In the Domain name field, type the Web server's domain name.
Note:
This field is optional, but specifying the domain name allows the SMTP connection to be set up according to RFC 821.Select an option under Mail Send Style:
Synchronous Mail—Sent from the process, such as Modify Attribute, that triggered the email. If an error occurs connecting to the mail server or the server is down, the email is not sent and cannot be regenerated.
Asynchronous Mail—Uses a thread to queue emails from all applications and sends them one at a time. If the mail server cannot be reached, the thread re-sends the email. Queued mails are saved to disk. If you select Asynchronous Mailer, specify the mail queue size.
Select an option under Mail Style.
Click Save to save your changes (or Cancel to exit the page without saving).
You can view the contents of the Identity Server cache, load the cache with new information, and clear the memory cache to resolve inconsistencies.
To view Identity System cache details
In the Identity System Console select System Configuration, then select Server Settings.
In the Server Settings page, click Cache to display the page.
Select the option you want to view the cache contents, or load or clear the memory cache.
See the Oracle Access Manager Deployment Guide for more information about managing caches.
In new installations, the Multi-Language feature is enabled by default. You can enable, disable, and specify preferred languages in the Identity System Console.
Note:
When you upgrade from an older version, the Multi-Language feature is disabled. To enable this feature complete the steps in the following procedure.From the Identity System Console, select System Configuration, then select Server Settings.
From the View Server Settings page, select Multi-Language.
The Manage Multiple Languages page appears. Details such as available languages, the order of preference, and whether a language is enabled or not appear on this page.
Determine which languages to enable or disable.
Enable—Select a language and click Enable to enable it.
Disable—Select a language and click Disable to disable it.
Click Back to go back to the Server Settings page.
Managing Identity Servers consists of tasks such as adding or deleting Identity Servers, and modifying an Identity Server's parameter values. See the Oracle Access Manager Installation Guide for details about installing an Identity Server. To remove a server completely, you must un-install it.
This section includes the following topics:
The following overview outlines how to set up multiple Identity Servers.
Task overview: Setting up multiple Identity Servers
Install the first Identity Server and a WebPass, then set up the Identity System as described in the Oracle Access Manager Installation Guide.
Add a new Identity Server instance in the Identity System Console, as described in the procedure "Viewing and Modifying Identity Server Parameters" .
Associate the new Identity Server instance with a WebPass and specify the priority as Primary, as described in "Managing Associations Between Identity Servers and WebPass".
Modify the WebPass instance to set the maximum connections to the appropriate number to communicate with all primary Identity Servers, as described in "Adding or Modifying a WebPass".
You must wait at least one minute before performing step 5 to ensure that the WebPass configuration file, webpass.xml, is updated with the new instance information. Otherwise, the WebPass instance may not receive the new information and cannot connect to the new Identity Server instance.
The actual amount of time you must wait depends on the interval set for this refresh, which is described in "Configuring the WebPass Poll Tracking Parameter".
Wait at least one minute before stopping all installed Identity Servers.
Install the new Identity Server and indicate that this is not the first Identity Server for this directory server, as described in the Oracle Access Manager Installation Guide.
You do not need to update the schema again.
Set up the new Identity Server you installed, as explained in the Oracle Access Manager Installation Guide.
When you want to add a new Identity Server instance to your installation, use the following procedure.
To add an Identity Server
In the Identity System Console, click System Configuration, then select Identity Servers.
The List all Identity Servers page appears with links to existing Identity Servers.
Click the Add button.
The Add a New Identity Server page appears.
Fill in the Name through Number of Threads fields as follows:
Name: Type the name of the Identity Server.
Hostname: Type the name of the machine on which the Identity Server is running.
Port: Type the port number of the Identity Server.
Debug: Specify whether you want to store debug information on the low-level traffic between the Identity Server and the WebPass.
Debug File Name: Type the name and path of the debug file. The default path is IdentityServer_install_dir/oblix/logs/debugfile.lst, where IdentityServer_install_dir is the directory where the Identity Server is installed.
Transport Security: Select the security method used for communications between the WebPass and the Identity Server:
Note:
Cert—Used if you manage an internal Certificate Authority (CA). Communications are encrypted using TLS v1. In addition, each element, both client and server, must present an X.509 certificate when establishing a connection. The certificate must be provided by a third party such as VeriSign.Maximum Session Time (Hours): Type the maximum period of time that a connection between the WebPass and Identity Server can remain open.
When the time expires, the connection closes and a new one is opened.
Number of Threads: Type the maximum for number of concurrent requests that the Identity Server is allowed.
Complete the Audit information for your environment.
Audit to Database Flag (Auditing On/Off): Selecting On directs audit information to a configured database. Off is the default.
Audit to File Flag (Auditing On/Off): Selecting On directs audit information to a file whose name you specify in the next field. Off is the default.
Audit File Name: Type the name of the auditing file where the Identity Server's auditing information is written.
You can specify an absolute or a relative path for the audit file for the Access or Identity Server. To specify a relative path, use either "." or ".." at the beginning of the path. For example, you can input the following relative path:
./auditfile.lst\
This relative path creates an audit file in the following location:
Component_install_dir\oblix\apps\common\bin\auditfile.lst
Where Component_install_dir is the root installation directory for the associated Access or Identity Server.
The following relative path:
../../../logs/auditfile.lst
Creates Component_install_dir\oblix\logs\auditfile.lst.
Note:
For IIS deployments, in order for your audit files to be visible, you must grant write permissions to the IIS user (the system user running the Web server) for the %TEMP% and %TMP% directories and to the audit file destination directory.Audit File Maximum Size (Bytes): Type the number of bytes an audit file can contain. When this amount is reached, the audit file is time stamped and saved, and a new file is created.
Audit File Rotation Interval (Seconds): Type a number representing the number of seconds that elapse before audit file rotation occurs. Rotation means that the audit file is time stamped and a new file is created. The default is 7200. A setting of 0 means that the audit file never times out, and audit information continues to be added to the file.
Fill in the Scope File Name field as follows:
Scope File Name: Type the name of the file that logs bug reports. When a bug report is generated, the information displayed on the page also is logged to a file. This parameter specifies the name of the file for Bug Report or OB_SCOPE messages.
Enter details for the SNMP state and agent registration port for your environment.
See "SNMP Monitoring" for details.
SMNP State: Selecting On enables SNMP monitoring. Off is the default.
SNMP Agent Registration Port: The port that the SNMP agent listens on.
Note:
Even if SNMP monitoring is On, to retrieve SNMP statistics you must configure your Network Management Station (NMS) to process the information defined in the Management Information Base (MIB). See details on the SNMP Agent MIB variables, later in this book.Click Save to finish defining your new Identity Server (or Cancel to exit without saving).
You use the following procedure in the Identity System Console to view or modify parameters.
To view or modify an Identity Server's parameters
In the Identity System Console, select System Configuration, then select Identity Servers.
A list of existing Identity Servers appears, displaying each server's name, hostname, and port number.
Click the name of an Identity Server to view its parameters.
The Details for Identity Server page appears. The server's parameters are listed on this page.
Click Modify.
The Modify Identity Server page appears.
Modify the parameters as necessary.
See "To add an Identity Server" on page 7-15 for information about each parameter.
Click Save to save your changes (or Cancel to exit without saving).
You use the following procedure in the Identity System Console to delete Identity Server parameters.
Note:
If you delete an Identity Server from the Console, an attempt to start that server from a command line will fail because the Identity Server's parameters have been deleted from the Console.To delete an Identity Server's parameters
In the Identity System Console, click System Configuration, then select Identity Servers.
A list of existing Identity Servers appears, displaying each server's name, hostname, and port number.
In the List all Identity Servers page, select the Identity Server you want to delete.
Click Delete.
When asked to confirm your decision, click OK.
The server's name is removed from the list of servers.
You can use the command line tool config_ois to manage tasks related to the Identity Server Service in the Windows Service window.
You can install the Identity Server Service and perform other tasks such as starting or stopping the service with the following commands:
Table 7-1 Commands for config_ois
| Command | Operation |
|---|---|
|
[-i install_dir] |
Specifies the installation directory for the Identity Server Service. |
|
-v |
Specifies the Service name. |
|
[-a <start, stop, query, install, remove>] |
Specifies the action to be performed. |
C:\IdentityServer_install_dir\identity\oblix\apps\common\bin\ config_ois.exe -q -i c:\IdentityServer_install_dir\identity -v Identity_ServiceName -a query
where IdentityServer_install_dir is the directory where Identity Server is installed and Identity_ServiceName is the name of the Identity Server Service.
The query displays the following information:
Sample_Srv configuration:
Service Type: 0x110
Start Type: 0x2
Err Control: 0x1
Binary path:
c:\COREid\identity\oblix\apps\common\bin\ois_server.exe
Load order group:
Dependencies:
Dependencies: LocalSystem
When installing components that communicate with a directory server, you specify the directory server with which the component communicates. Each component communicates with the directory for a specific purpose:
Identity Server: When you install an Identity Server, you designate an LDAP directory server where configuration data is to be stored, and you designate where user data is stored. The user data may be on the same directory server where the configuration data is stored, or it may be a different directory server.
Policy Manager and Access Server: When installing a Policy Manager or an Access Server, you also designate where user data and configuration data are stored. Configuration data includes system configuration, attribute definition, attribute access control, workflow definition, and workflow instance data. Additionally, you designate where access policy data is stored.
Note:
As of release 7.0, you may have user data stored on one directory server type and configuration and policy data stored together on a different directory server type. For data storage details, see the Oracle Access Manager Installation Guide.The following topics provide more information:
For each type of data that Oracle Access Manager requires—configuration data, user data, and policy data—an LDAP directory server profile identifies the precise location of the data. The location of policy and configuration data is also stored in.xml files for the Identity Server, Access Server, and Policy Manager. A directory server profile contains the connection information for one or more directory servers that share the same namespace and operational requirements for Read, Write, Search, and so on. The connection information includes a name, a domain or namespace to which it applies, a directory type, and a set of operations. A default directory server profile is created automatically each time you install the Identity Server and specify new directory server connection information.
You can create additional LDAP directory server profiles for load-balancing and failover. You can create directory server profiles that correspond to the partitions of your directory information tree (DIT). Partitioning can potentially increase performance by freeing CPU cycles to perform read and write operations on a specific portion of the DIT. This can be especially benefical in installations with multiple directory servers and machines.
You can also create LDAP directory server profiles that specify different operations for master and replicated copies of the DIT. For example, you could specify that write operations take place only in the master, and the replica can accept only read operations.
Note:
You must always support read, search, modify, create, and delete operations for the directory server profile containing the Oblix tree. You cannot create a read-only or write-only directory server profile for the Oblix tree. If you change settings for the configuration or policy data directory profile, you need to rerun Identity Server and Policy Manager setup and reconfigure the Access Server. For details, see "Rerunning Setup Manually" on page 7-29.When you install and configure a new Oracle Access Manager component, various profiles are stored in a configuration directory server as follows:
obcontainerId=DBAgents,oblix-root-node
Where oblix-root-node is the top-level node for Oracle Access Manager data. If user, policy, and configuration data are stored in the same branch of the directory server, a single profile that contains all of the data can be created for each component that requires a profile. If user, policy, and configuration data are stored in disjoint branches or in different directory servers, separate profiles are required.
Table 7-2 summarizes creation of the directory server profiles. Note that no new profiles are created for additional instances of the Access Server.
Table 7-2 Directory Server Profiles That Are Created During Installation
| Installation and Configuration Scenario | Profiles Created for the First Identity Server and Policy Manager | Profiles Created for the Second Identity Server | Profiles Created For the Second Policy Manager |
|---|---|---|---|
|
User, configuration, and policy data arestored in one directory server. The user search base is the top node, the configuration base is a descendent of the user search base, and the policy base is a descendent of the configuration base. |
New profiles:
|
Profile for the new Identity Server |
No new profiles |
|
Configuration and policy data are stored in same directory, while user data is stored in a separate directory. Or, the policy base is a descendent of the configuration base, and the configuration base is disjoint from the user search base. |
New profiles:
|
New profiles:
|
No new profiles |
|
User, configuration and policy data are located in three different directories servers. Or, user, configuration, and policy data are each in a different disjoint domain. None of these data stores is a descendent of another one. |
New profiles:
|
New profiles:
|
One new policy data profile is created for all new Identity Servers if there is no existing profile for the policy base. |
Note:
If you install a second Identity Server and notice that an exiting database profile has changed, be sure that you specified a unique ID for the new Identity Server. Using an existing ID can cause profiles to be overwritten.The following screen shot shows the Configure Profiles page in the Identity System Console.
The top portion of Configure Profiles page shows details for the directory server that contains user data and configuration data. The central portion of the page includes links you can use to configure LDAP Directory Server Profiles. The bottom portion of the page includes links to configure RDBMS profiles. For details about RDBMS profiles, see "Managing RDBMS Profiles".
Clicking the Directory Server link displays the Directory Server Configuration page. If you change the communication mode for the directory server, or host name or port number, you must also change this information on the Directory Server Configuration page and re-run the setup program. See "Changing Transport Security Modes" for details about this type of change.
The middle portion of the Configure Profiles page is titled "Configure LDAP Directory Server Profiles" followed by a list of links to LDAP directory server profiles for user data, configuration data, and policy data. You can click a profile link to review specifications and supported operations for the profile. You can specify all operations or specific operations, as listed in Table 7-3.
Table 7-3 Supported Directory Server Operations
| Category | Operation | Comments |
|---|---|---|
|
All Operations |
All operations are allowed (the default). |
|
|
Search |
Search Entries Authenticate User |
The Authenticate User operation allows users to authenticate within the name space of the directory server profile. Selecting this option results in a list of the login pages for Authentication Domain. |
|
Read |
Read Entry |
This operation enables the directory server profile to support "Read Schema" as well. |
|
Write |
Create Entry Modify Entry Delete Entry Change Password |
The Change Password operation allows users to change their password over an ADSI or SSL connection while assigning other more frequently used operations like search to different directory server profiles. |
The following procedure shows how to create a directory server profile.
To create a directory server profile
From the Identity System Console click System Configuration, then click Directory Profiles.
Click Add to create a new LDAP directory profile and display the Create Directory Server profile page.
Note:
To modify a directory server profile, click the name of the profile in the list under Configure LDAP Directory Server Profiles. In this case, the Modify Directory Server Profile Page appears as described in "Modifying an LDAP Directory Server Profile".
Note:
Fields marked with an * are required.In the Name field, enter a name for the directory server profile.
This name is for informational purposes only. The Identity System uses the naming convention default <Identity Server id> for all default directory server profiles automatically created during Identity System installation.
In the Name Space field, enter the searchbase for the directory server profile.
Note:
Use caution that this namespace does not overlap with other directory server profile namespaces. Overlapping namespaces result in duplicate entries. Exceptions to overlapping name spaces include a directory server profile for a Microsoft Active Directory sub-domain, and the directory server profile containing the configuration DN.Select the type of directory server.
Siemens DirX and Sun: When using either Siemens DirX or Sun (formerly iPlanet) exclusively, you have the option to store data either separately or together, as discussed in the Oracle Access Manager Installation Guide.
Oracle Data Anywhere: Requires integrating with the Oracle Virtual Directory Server (VDS).
Oracle Data Anywhere is a data management layer that aggregates and consolidates user data from multiple sources (including RDBMS and LDAP directories) into a virtual LDAP tree that can be managed by the Identity System and used to support authentication and authorization using the Access System.
The LDAP directory branches containing configuration and policy data must reside on one or more directory servers other than the one hosting VDS or user data. Identity System applications only recognize configuration and policy information that resides outside the VDS virtual directory.
Caution:
Before installing for use with Oracle Data Anywhere and VDS, be sure to read the chapter about integrating with VDS in the Oracle Access Manager Integration Guide.Active Directory: If you select Active Directory, specify whether to use ADSI (Active Directory Service Interfaces) for change password operations. Selecting the ADSI option implies you do not have to set up an LDAP/SSL connection for password changes. If you do not use ADSI, Oracle Access Manager uses an SSL connection to change the password. See "Configuring for ADSI".
If you have already set up LDAP/SSL for all other regular operations to the directory server, you do not need to set up the certificate server, import the CA certificate, and so forth. Otherwise, you need to configure LDAP/SSL for the password change.
See the Oracle Access Manager Installation Guide for more information.
Dynamic Auxiliary Classes—If you are using dynamic auxiliary classes with Active Directory, select Yes for Dynamic Auxiliary to associate a dynamic auxiliary class with a structural object class in Active Directory 2003.
See "Deploying with Active Directory" for more information.
Note:
You can enable either dynamic or static auxiliary classes in Active Directory 2003.Specify the supported operations for this directory server profile, as listed in Table 7-3.
Indicate which servers are to use this profile.
All Oracle Access Manager Components: Select this option if you want each component server in this installation to share the same profile.
Identity Servers: Select this option if you want only the Identity Servers to share this profile. If you want a particular Identity Server to use this profile, select the server name from the list box provided.
AAA Servers: The AAA Server option represents the configuration option for the Access Server. You are prompted to create a database profile whenever you add a new Access Server. For details about adding an Access Server instance, see the Oracle Access Manager Access System Administration Guide.
Click Add to associate a directory server instance (database instance) with this profile, and assign the server type as primary or secondary.
See "To add or modify a database instance for an LDAP directory server profile" for details.
Specify the number of maximum active servers you want (the number of primary and secondary database instances to connect to for load balancing).
A default value of 1 indicates that no load balancing takes place.
A value greater than 1 distributes database requests across all database instances, depending on which database instance has the shortest job queue. This ensures that the job is processed as quickly as possible.
For more information on load balancing, see the Oracle Access Manager Deployment Guide.
Specify the Failover Threshold.
The value specifies the minimum number of primary servers that must be running. If the number of primary servers running is less than the specified number, a failover occurs. It is recommended that this value be the same as the number of maximum active servers. This ensures that failover to any secondary server happens immediately when a primary server goes down.
The default value is 1. This indicates that failover to a secondary server only occurs when there are no primary directory servers to which the Identity Server can connect.
Note:
Oracle recommends that this value match the number of maximum active servers to ensure that failover to any secondary server happens immediately when a primary server goes down. For more information on failover and related parameters, see the Oracle Access Manager Deployment Guide.In the Sleep For (Seconds) field, enter the number of seconds before the watcher thread wakes up and attempts to reestablish a connection to one or more downed primary servers.
Note:
If a primary server is available when failover occurs, the Identity Server will fail over to the primary server first.In the Max. Session Time (Min.) field, specify the number of minutes that the Identity Server keeps a connection to the directory before attempting to reconnect.
The default value is 0 (unlimited). If you see the memory usage rise for the Identity or Access Server or the Policy Manager, Oracle recommends to change this value to 600 (10 hours).
If this profile is ready for use, select Enable Profile.
The following screen shot shows the lower half of the configuration page:
Select Save, Cancel, or Reset as follows:
Click Save to save your changes.
Click Cancel to exit this page without saving.
Click Reset to reset all settings to the default settings.
Click OK to confirm your addition.
Restart your Identity Servers to enable the new profile.
The middle section of the Configure Profiles page, under the heading Configure LDAP Directory Server Profiles, contains a list of configured directory server profiles.
To view an LDAP directory server profile
From the Identity System Console, click System Configuration.
On the System Configuration page, click Directory Profiles.
The Configure Profiles page appears.
The middle section of the page, under the heading Configure LDAP Directory Server Profiles, contains a list of configured directory server profiles.
Click the link for the directory server profile that you want to view.
The Modify Directory Server Profile page appears.
There may be occasions when you need to modify an existing LDAP directory server profile.
To modify an LDAP Directory Server Profile
From the Identity System Console, select System Configuration.
On the System Configuration page, click Directory Profiles.
On the Configure Profiles page, click the link for the directory server profile that you want to modify from those listed under the title 'Configure LDAP Directory Server Profiles'.
Refer to "Creating an LDAP Directory Server Profile" for details about parameters.
Make the changes you need, then click Save to confirm them.
Restart your Identity Servers to enable the new profile.
You need to rerun the setup after completing any of the following operations on a directory server profile for configuration and policy data:
Change directory server configuration options in the System Console.
Create a new directory profile for configuration and policy data.
Delete a directory profile belonging to configuration and policy data.
Modify a directory profile for configuration and policy data.
Add or change a directory instance within a profile.
Note:
You also need to rerun setup when you make specific changes (those marked with an asterisk, *) on the Directory Server Configuration page.Rerunning setup must occur in a specific sequence.
Task overview: Rerunning system setup
Rerun Identity System setup, as described in "Rerunning Identity System Setup" .
Rerun Policy Manager setup, as described in "Rerunning Policy Manager Setup" , if needed.
Reconfigure the Access Server, as described in "Reconfiguring the Access Server" .
Modifying or removing the status parameter in setup.xml tells the Identity System that installation is not complete and permits you to rerun setup.
To rerun Identity System setup
Shut down all but one Identity Server if there is more than one running.
Go to the only remaining running Identity Server host and open the setup.xml file:
IdentityServer_install_dir/identity/oblix/config/setup.xml
Remove the status parameter (or change the status parameter value from "done" to "incomplete"), as shown in the following example:
<NameValPair ParamName="status" Value="incomplete"></NameValPair>
Save the file.
Restart the Identity Server.
From your Web browser, launch the Identity System Console.
You will see a Setup page similar to the one that appears during the initial Identity System setup.
Initiate setup again and specify the new information.
After completing the setup, restart the other Identity Servers.
The other Identity Servers should pick up the new information.
Complete the next procedure to rerun Policy Manager setup.
After rerunning setup for the Identity System, if your implementation includes the Access System, you are ready to setup the Policy Manager manually. Modifying or removing the status parameter in setup.xml permits you to rerun Policy Manager setup.
Shut down all but one Policy Manager Web server if there is more than one running.
Go to the only remaining running Policy Manager host and open the setup.xml file:
PolicyManager\oblix\config\setup.xml
Remove the status parameter (or change the status parameter value from "done" to "incomplete"), and save the file as shown in the following example:
<NameValPair ParamName="status" Value="incomplete"></NameValPair>
Restart the Policy Manager Web server.
From your Web browser, launch the Access System Console.
You will see a Setup page similar to the one that appears during the initial Access System setup.
Initiate setup again and specify the new information.
After completing setup, restart the other Policy Manager Web servers.
The other Policy Managers should pick up the new information.
Rerun Access Server, as described in "Reconfiguring the Access Server".
After manually rerunning setup for the Policy Manager, you need to reconfigure the Access Server as indicated in the following procedure. For additional information on using the configureAAAServer tool, see the Oracle Access Manager Access System Administration Guide.
To reconfigure the Access Server
Locate the configureAAAServer tool.
For example:
AccessServer_install_dir/access/oblix/tools/configureAAAServer
Use the following command with the configureAAAServer tool to set up the Access Server:
configureAAAServer install -i AccessServer_install_dir
Specify new information.
Restart your Access Server.
A directory server profile contains the bind information for a particular LDAP directory server, including the server name, the host machine, the port, the root DN, and the password. As part of a directory server profile, you can configure a database instance. When you define such a database instance, Oracle Access Manager validates the configured host and port against the supplied bind credential. The directory server corresponding to the database instance must be running when you configure it.
Note:
A database instance within an LDAP directory server profile is distinct from a database instance within an RDBMS profile. An RDBMS profile is used to connect Oracle Access Manager to an external, ODBC 3.0-compatible relational database. See "Managing RDBMS Profiles" .An LDAP directory server profile consists of one or more database instances, which are used for load balancing and failover. The directory server profile balances the load among its instances according to the maximum number of active servers; it experiences failover among its instances according to the failover threshold.
Note:
Reconfiguring the Identity System to point the configuration directories to a new directory server causes /IdentityServer_install_dir/data/common to be reset. Specifically, in workflowdbparams.xml, the parameter wfinstancenotrequired=true is reset to false. After reconfiguring a directory server instance, manually reset the parameter wfinstancenotrequired to true.When you add a directory server instance, you can specify whether or not to enable LDAP referrals. A referral redirects a client request to another server, to find the requested information in another location. A referral contains the names and locations of objects.
If you choose to enable LDAP referrals when you add a directory server instance, you need to set the enableLDAPReferral parameter to true in the following file:
install-dir\oblix\data\common\ldapconfigdbparams.xml
Where install_dir is the installation directory for the Policy Manager, Access Server, or Identity Server.
The following is an example of this file for Active Directory:
BEGIN:vCompoundList
specialAttrs:
BEGIN:vNameList
userPassword:( 2.5.4.35 NAME 'userPassword' DESC
'Standard Attribute' SYNTAX '1.3.6.1.4.1.1466.115.121.1.5' )
sAMAccountName:( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' DESC 'sAMAccountName' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
END:vNameList
useOIDNamingAttribute:false
dynamicAuxiliary:false
enableLDAPReferral:true
END:vCompoundList
To add or modify a database instance for an LDAP directory server profile
From the Identity System Console, click System Configuration.
On the System Configuration page click Directory Profiles.
Click the link for the directory server profile to which you want to add a database instance.
The Modify Directory Server Profile page appears.
Scroll down to Database Instances and click the Add button (to edit/modify an existing database instance, select it form the list of database instances).
The Create Database Instance (or Modify Database Instance) page appears.
Note:
The fields for the Modify Database Instance page for an LDAP Directory Server Profile differ from those for the Modify Database Instance page for an RDBMS. See "Adding or Modifying an RDBMS Database Instance" for details.
Fill in the fields as follows:
Name: Enter a name for the directory server instance.
Machine: Enter the name of the computer hosting the directory server instance.
Port Number: Enter the port number for the directory server.
Root DN: Enter the Root DN (bind DN) of the directory server user with administrative privileges.
Root Password: Enter the password of the directory server user with administrative privileges.
Time Limit: Specify the maximum amount of time allowed for a request to the directory server.
The default value is 0 seconds, which means that the server determines the time. The database-instance setting takes precedence over this setting.
Size Limit: Specify the maximum number of entries the directory server can return for a search operation.
The default value is 0 entries, which indicates that the server determines the number.
Flags: Select either of the following:
SSL: Directory server processes that use SSL. This requires initial certificate configuration. Refer to your directory server documentation for information.
Referral: Specifies whether the directory server profile should trace LDAP referrals for this directory server. The same bind credentials (Root DN and password) are used to log in to the referral server.
Fast Bind (only for AD on Windows Server 2003): Authenticates a user name and password without returning a security token, unlike simple bind. This is faster than simple bind for applications that only perform authentication.
Secure Port: Specify the port where you access the directory server.
Leave this field blank if you are not using SSL or if you are using Active Directory with ADSI for change password.
Initial Connections: Specify the initial number of connections used to connect to the directory server.
These connections are shared among all user requests. The minimum is 1.
Maximum Connections: Specify the maximum number of connections allowed to the directory server.
The default is 1. A different DB agent is used for different types of operations. Note that the Maximum Connections field is implemented for a specific agent. The grand total of connections that can be opened can be much higher than the value specified in this field. See the information on configuring the directory connection pool in the Oracle Access Manager Deployment Guide for details.
Click Save to save your settings.
Clicking Cancel exits without saving, and clicking Reset reverts to the last saved settings.
You may want to remove an LDAP directory server instance.
To delete a directory server instance for an LDAP directory server profile
From the Identity System Console select System Configuration, then click Configure Directory Options.
The Configure Directory Server Profiles page appears. All the directory server profiles are listed on this page.
Click the directory server profile to which you want to add an instance.
The Modify Directory Server Profile page appears.
In the Modify Directory Server Profile page, select the Database Instance that you want to delete.
Click Delete.
The directory server instance is deleted.
Some directories such as the Oracle Internet Directory allow you to configure multiple searchbases, sometimes referred to as disjoint searchbases or realms. These disjoint searchbases or realms consist of nonoverlapping directory trees, for example:
o=company,c=us
o=oracle,c=us
If you want Oracle Access Manager to manage data in more than one of these searchbases, you must configure the Identity and Access Systems separately for each searchbase.
The following procedures assume that you have already defined the disjoint searchbases (or realms) in your directory.
To configure the Identity System to work with a disjoint searchbase
From the Identity System Console click System Configuration, then click Directory Profiles.
Add a separate directory server profile for each new disjoint searchbase that you want to support.
See "Creating an LDAP Directory Server Profile" for details. Ensure that the name space that you provide matches exactly the name space in the directory.
Restart the Identity Server and the Web server running the Identity Server.
Return to the Directory Profiles page: From the Identity System Console click System Configuration, then click Directory Profiles.
Click the Directory Server link on the Directory Profiles page.
In the Disjoint Search Base field, enter the name space of the first disjoint searchbase.
This must be identical to the name space provided in the directory server profile.
Click Add to configure additional disjoint searchbases.
For each new disjoint searchbase, configure new permissions for users who have entries in the searchbase.
See "Allowing Users to View and Change LDAP Data" for details.
Add Identity Administrators and Delegated Identity Administrators for each disjoint searchbase.
See "Specifying Identity System Administrators" for details.
Open the following file in a text editor and ensure that the value for the whichAttrIsLogin parameter in this file matches the user attribute in the directory:
IdentityServer_install_dir/oblix/apps/common/bin/globalparams.xml
To configure the Access System to work with a disjoint searchbase
Complete the steps in the procedure "To configure the Identity System to work with a disjoint searchbase".
Open the following file in a text editor and ensure that the value for the whichAttrIsLogin parameter in this file matches the user attribute in the directory:
PolicyManager_install_dir/oblix/apps/common/bin/globalparams.xml
In the Access System Console, create an authentication scheme that uses the appropriate credential mapping parameters.
The syntax for the authentication scheme is as follows:
obMappingBase="%domain%",obMappingFilter="(&(&(objectclass= objectclassname)(loginattribute=%userid%))(|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))",obdomain="domain"
Where objectclassname is the name of the Person object class, for example gensiteorgperson and loginattribute is the name of the login attribute for the Person object class, for example, genuserid. See Oracle Access Manager Access System Administration Guide for details.
For example, if your disjoint searchbases use the gensiteorgperson as the Person object class and genuserid as the login attribute, you might create an authentication scheme as follows:
obMappingBase="%domain%",obMappingFilter="(&(&(objectclass=gensiteorgperson) (genuserid=%userid%))(|(!(obuseraccountcontrol=*))(obuseraccountcontrol= ACTIVATED)))",obdomain="domain"
In the Policy Manager, modify the relevant authentication rules to use the appropriate authentication scheme.
See Oracle Access Manager Access System Administration Guide for details.
In the Policy Manager, configure the /access and /identity policy domains to return the value obuniqueID in the HTTP_OBLIX_UID header variable upon successful authentication.
In the authentication rules for these policy domains, configure the following authentication success action. Note that the obuniqueid attribute returns any value configured for the specific login attribute used by each searchbase in the directory:
Type—HEADERVAR
Name—HTTP_OBLIX_UID
Return Attribute—obuniqueid
Oracle Access Manager connects to external, ODBC 3.0-compatible relational databases through RDBMS profiles. Currently user access profile reporting and the audit-to-database features make use of RDBMS profiles. Each profile can contain multiple database instances for failover if the primary instance of the database goes down.
Note:
RDBMS profiles contain database instances. These database instances are distinct from database instances that are configured as part of LDAP directory server profiles. The latter are used to load balance and failover for LDAP directories.This section discusses the following topics:
The steps to either add or modify an RDBMS profile are similar and are described in the following procedure. The fields you complete are described in Table 7-4.
Table 7-4 Field Descriptions for Adding or Modifying an RDBMS Profile
| Field | Description |
|---|---|
|
Name |
Choose a self-explanatory name for your RDBMS profile. |
|
Database Connection Type |
Choose the connection type that your database uses, if you have configured auditing to a database. See "Auditing" for details. |
|
Used By |
Check the box corresponding to the feature for which you will be using the RDBMS profile. Currently, the choices are user access privilege reporting and auditing to database. |
|
You can create multiple copies of the database for use in failover as follows:
|
|
|
Maximum Active Servers |
This is the maximum number of servers that can be connected to the relational database at any given time. |
|
Failover threshold |
When the number of connected primary servers falls to this number, failover occurs. |
|
Sleep For (Seconds) |
Once a connection fails, this many seconds must elapse before failover takes place. |
|
Max. Session Time (Min.) |
The connection to the database is discarded after this many minutes, even if it is functioning, and a new connection is established. |
|
Enable Profile |
Make sure to check this box if you want the profile to be active. |
To add or modify an RDBMS profile
From the Identity System Console select System Configuration, then click Directory Profiles.
The Configure Profiles page appears. All the directory server profiles are listed on this page.
The Configure RDBMS Profiles section is at the bottom of the Configure Profiles page.
Select from the RDBMS Profile list the name of the profile you want to edit (or click Add to create a new profile).
Complete or modify the fields on the Add RDBMS Profile (or Modify RDBMS Profile) page, as described in Table 7-4.
When you are satisfied with the information in the fields, click Save to commit the changes.
The steps to create or modify a database instance for an RDBMS database profile are so similar that they are combined in the following procedure. In either case, you must complete fields for the information in Table 7-5.
Table 7-5 Field Descriptions to Add or Modify a Database Instance in an RDBMS Profile
| Field | Description |
|---|---|
|
Name |
The name of the database instance |
|
DSN Name or Global Database Name |
If you configure database auditing with an ODBC connection type, the DSN Name field appears. It identifies a unique data-source definition to all the clients that access a given data source. (The term DSN is often used incorrectly to denote an entire ODBC data-source definition.) If you configure database auditing with an OCI connection type, you specify a Global Database Name (GDN) in the database instance definition. See "About RDBMS Profiles for Database Auditing" for details. |
|
User name |
The name of the administrator with access privileges to this database instance |
|
Password |
The password for this database instance |
|
Time Limit |
The number of minutes after which the connection to the database is broken and then replaced with a fresh connection |
|
Size Limit |
The maximum size of the database |
|
Initial Connections |
The number of primary and secondary servers connected to this database instance when it is initialized |
|
Maximum Connections |
The total number of primary and secondary Access Servers that can be connected to this database instance |
To add or modify a database instance for an RDBMS profile
From the Identity System Console select System Configuration, then click Directory Profiles.
The Configure Directory Server Profiles page appears.
In the Configure RDBMS Profiles section, click Add to create a RDBMS profile, or select from the list the name of the RDBMS profile you want to modify.
Depending on your selection, either the Add RDBMS Profile or Modify RDBMS Profile page appears.
In the Database Instances section, click the Add button to create a new instance (or select from the list the name of the instance you want to edit).
Complete the fields on the Modify Database Instance or Add Database Instance page.
Field descriptions appear in Table 7-5.
Click Save to commit the changes when you are satisfied with the information in the fields on the page.
You first install WebPass after installing the Identity Server. After you set up the Identity System, you can install and configure multiple WebPass instances. Each WebPass instance is installed and configured separately. When a WebPass instance is installed, you supply several required parameters. A Master Administrator can modify these parameters and supply additional information, such as the failover threshold, in the Identity System Console.
When a user requests access to a Web server resource, WebPass redirects the request to an Identity Server, which then checks the user's identity through the directory server. You must configure a WebPass plug-in for each Web server.
See the Oracle Access Manager Installation Guide for information about installing WebPass. Topics in this section include:
WebPass configuration occurs using the Identity System Console, Configure WebPass function.
From the Identity System Console select System Configuration, then select WebPass.
The List all WebPasses page appears. From this page you can add, modify, or delete a WebPass.
To view information about a WebPass, click the link for the WebPass.
The Details for WebPass page appears. All the information about the WebPass instance is listed on this page.
Adding a new WebPass involves adding the instance in the Identity System Console, installing WebPass on the Web server host, and updating the Web server configuration to establish communications between the WebPass and the Web server. Use the following procedure to add the instance. See the Oracle Access Manager Installation Guide for other details.
From the Identity System Console click the System Configuration sub-tab, then click WebPass in the left navigation pane.
The List all WebPasses page appears. From this page you can add, modify, or delete a WebPass.
From the Configure WebPass page, click Add.
The Add a new WebPass page appears.
In the Name field, type a name for this WebPass instance.
Note:
You cannot change the name you save with this instance. To change the name, delete this instance and reconfigure it with a different name.In the Hostname field, type the name of the Web server instance hosting this WebPass.
In the Web Server Port field, type the port number the Web server instance is listening to.
The maximum value is 65535.
In the Maximum Connections field, specify the maximum number of connections this WebPass opens to Identity Servers.
The minimum number of connections is 1. You may want to specify more connections for load balancing and failovers.
In the Transport Security field, you can modify the security mode that was specified when Oracle Access Manager was installed.
The transport security mode specifies the degree of security during communications between the WebPass and the Identity Server. See "Changing Transport Security Modes" for details.
The supported transport security modes are as follows:
Open: No transport security.
Simple: Provides basic security. Communications are encrypted using Transport Layer Security, RFC 2246 (TLS v1). Communicating elements authenticate one another using a password-based mechanism. All elements that use simple security must use the same password throughout the installation. Oracle Access Manager provides the certificate that performs the authentication.
Cert:Used if you manage an internal certificate authority (CA). Communications are encrypted using TLS v1. Both client and server must present an X.509 certificate from a third party (such as VeriSign) when establishing a connection.
Note:
Your Identity Servers and WebPasses must use the same transport security mode. Repeat these steps as necessary for each installed component.In the Maximum Session Time (hours) field, specify the maximum period of time in hours before the connection between the WebPass and Identity Server is closed and a new one is opened.
In the Failover Threshold field, specify the minimum number of connections to Primary Identity Servers.
If this number cannot be met using primary servers, WebPass attempts to do so using secondary servers. For example, if you type 4 in this field, and the number of available connections to primary Identity Servers falls to 3, WebPass attempts to open a connection to a secondary server.
For details about configuring failover between WebPass and the Identity Server, see the Oracle Access Manager Deployment Guide.
In the Identity Server Timeout Threshold field, specify how long (in seconds) the WebPass attempts to contact a non-responsive Identity Server before it considers it unreachable and attempts to contact another.
Oracle recommends a timeout value of -1, which indicates that there is no timeout. If you set this value to a low number, you run a risk of the the socket connection closing before a reply from the Identity Server is received. If the Identity Server takes longer to service a request than the value of the timeout threshold, the WebPass abandons the request and attempts to contact another Identity Server with the request until the Identity Server. However, if all Identity Servers take longer to service the request than the value of the timeout threshold, the retries continue until the servers are shut down. You can configure a limit on the number of retries that the WebPass performs for a non-responsive server using the client_request_retry_attempts parameter in globalparams.xml. See "To configure the number of retries to a non-responsive Identity Server" for details.
In the Sleep For (seconds) field, specify the interval at which WebPass checks its connection with the Identity System.
Along with checking for a minimum number of connections, the same check also tries to reestablish primary server connections when secondary connections are currently in use because the failover threshold was not met.
Click Save to add the WebPass plug-in (or Cancel to exit this page without saving).
If you click Save, this WebPass plug-in appears on the List all WebPasses page.
Associate the WebPass plug-in with one or more Identity Servers, as described in "Managing Associations Between Identity Servers and WebPass".
From the Identity System Console, click the System Configuration sub-tab, then click WebPass in the left navigation pane.
The List all WebPasses page appears. From this page you can add, modify, or delete a WebPass.
In the List all WebPasses page, click the name of the WebPass that you want to modify.
The Details for WebPass page appears.
Click Modify.
The Modify WebPass page appears.
Modify the parameters as needed.
Note:
See "Adding or Modifying a WebPass" for more information on the parameters you will modify.Click Save to save your changes (or Cancel to exit this page without saving).
Removing a WebPass means that you remove it from the list of configured WebPass instances. To delete a WebPass from the Web server instance, you must uninstall it.
From the Identity System Console, click the System Configuration sub-tab, then click WebPass in the left navigation pane.
The List all WebPasses page appears. From this page you can add, modify, or delete a WebPass.
In the List all WebPasses page, select the checkbox next to the WebPass instance that you want to remove.
Click Delete.
When prompted, click OK to confirm the action.
The WebPass instance is removed from the list of configured WebPasses.
Note:
If you remove a WebPass instance in the Identity System Console but do not run the uninstall program, it will be added to the directory server again when you restart the Web server.Occasionally you may need to modify the parameters of a WebPass. You modify some parameters, such as Maximum Session Time and Failover Threshold, through the Identity System Console. You can use the command line tool setup_webpass to change other parameters, such as the host machine name and transport security mode.
Typically, you use the command-line tool to change the transport security mode. This tool can be used in both Windows and Solaris installations.
To modify a WebPass through the command line
Navigate to
WebPass_install_dir\identity\oblix\tools\setupWebPass
where WebPass_install_dir is the directory where WebPass is installed.
From the setupWebPass directory, run the setup_webpass tool.
You can specify parameters using the commands in Table 7-6.
Table 7-6 Commands for setup_webpass
| Command | Operation |
|---|---|
|
[-i install_dir] |
Specifies the installation directory for the WebPass |
|
[-q] [-n WebPass _ID] |
Specifies the WebPass ID |
|
[-h Identity_Server_Host_Name] |
Specifies the machine name where the Identity Server is installed |
|
[-p Identity_Server_port_#] |
Specifies the port number of the machine where the Identity Server is installed |
|
[-s open|simple|cert |
Specifies the transport security mode |
|
[-P simple|cert mode password] |
Specifies the password for simple or cert transport security mode |
|
[-c request|install] |
Specifies a certificate request or installation |
To reconfigure transport security mode through the command line
To reconfigure a WebPass transport security mode, run the following command from the command line:
setup_webpass -i WebPass_install_dir -m
Select the transport security mode for WebPass:
| If you select Open | If you select Simple | If you select Cert |
|---|---|---|
| The transport security mode is reconfigured to run in Open mode. | The system prompts you for the password. |
|
For Cert mode, after you enter the information, a certificate request is generated and placed in Identity Server_install_dir\identity\oblix\config\ois_req.pem file, where IdentityServer_install_dir is the directory where the Identity System is installed
You must have this certificate request signed by the Certificate Authority.
If you specify a certificate installation, the system prompts you for the full paths to the location of the Certificate Key file, the Certificate file, and the Certificate Chain file.
After you specify the paths, the transport security mode is reconfigured. See "Changing Transport Security Modes" for details.
To change the transport security mode password
Run the following command from the command line:
setup_webpass -i WebPass_install_dir -k
Enter the following information:
The old password
The new password
Reconfirm the new password
The password is changed.
You must select one or more Identity Servers to receive requests from a WebPass. A single Identity Server can be associated with multiple WebPasses. You can view a list of primary and secondary Identity Servers that are associated with a WebPass instance. You can also modify the number of connections that have been configured between an Identity Server and a WebPass for load balancing and failover purposes, as described in the following procedures:
From the Identity System Console, click the System Configuration sub-tab, then click WebPass in the left navigation pane.
The List all WebPasses page appears. From this page you can add, modify, or delete a WebPass.
Click the link for a WebPass.
The Details for WebPass page appears.
Click the List Identity Servers button.
A page appears that lists the primary and secondary servers configured for the WebPass.
Click the link for an Identity Server to view details for it.
The Details for Identity Server page appears.
From the Identity System Console click the System Configuration sub-tab, then click Identity Servers in the left navigation pane.
The List all Identity Servers page appears. From this page you can add, modify, or delete a WebPass.
Click the link for the appropriate server.
The Details for Identity Server page appears.
In the Details for Identity Server page, click Modify.
The Modify Identity Server page appears, listing the Identity Server details.
Change the value in the Number of Threads field, as needed.
Click Save to save your changes.
Restart the Identity Server.
From the Identity System Console, click the System Configuration sub-tab, then click WebPass in the left navigation pane.
The List all WebPasses page appears. From this page you can add, modify, or delete a WebPass.
Click a link for the appropriate WebPass.
In the Details for WebPass page, click List Identity Servers.
The next page lists the Primary and Secondary servers associated with the WebPass.
Click Add.
The Add a new Identity Server to the WebPass page appears.
In the Select Server list, select an Identity Server.
Indicate whether this Identity Server is a Primary or Secondary server.
This information is required for load balancing and failovers.
In the Number of connections box, specify the maximum number of connections the WebPass instance opens to this Identity Server.
The minimum is 1. You may want to add more connections for load balancing and failover.
Click Add to associate this Identity Server with the WebPass.
Open the following file in a text editor:
identity_installdir/apps/common/bin/globalparams.xml
Add the client_request_retry_attempts parameter to this file.
The following is an example:
<SimpleList>
<NameValPair
ParamName="client_request_retry_attempts" Value="3">
</NameValPair>
</SimpleList>
If the Identity Server takes longer to service a request than the value of the Identity Server Timeout Threshold, the WebPass continues to try to contact the Identity Server with the request. This parameter enables you to set a limit on the number of retries that the WebPass attempts. This parameter takes an integer value. The default of -1 means that an unlimited number of retries are possible.
Occasionally, you may need to disassociate a WebPass instance from an Identity Server. For example, the machine resources in your division may be reallocated. In this scenario, the associations between WebPass and an Identity Server may no longer be valid. So you must disassociate them from each other. If you do not disassociate them, WebPass continues to poll for the Identity Server and slows down the Web server's performance.
Note:
You cannot disassociate an Identity Server if it is the only primary server configured for a WebPass.To disassociate an Identity Server from a WebPass
From the Identity System Console, click the System Configuration sub-tab, then click WebPass in the left navigation pane.
Click an existing WebPass.
Click List Identity Servers.
Select the check box next to the Identity Server you want to disassociate.
Click Delete.
When prompted, click OK to confirm your decision.
The WebPass instance will no longer communicate with the Identity Server.
WebPass sends an update request to the Identity Server based on an interval specified in the webpass.xml file. The default value is 60 seconds.
When responding to an update request, the Identity Server reads configuration information that was specified using the Identity System Console and stored in the directory. If the refresh parameter in webpass.xml is set to true, the Identity Server updates webpass.xml with the latest information, which includes the latest settings for:
Maximum Connections: The maximum number of connections this WebPass opens to Identity Servers
Maximum Session Time (Hours): The maximum period of time that a connection between the WebPass and Identity Server can remain open
Timeout Threshold: The amount of time the WebPass attempts to contact a non-responsive Identity Server before it considers it unreachable and attempts to contact another
Failover Threshold: If the number of primary servers running is less than the specified number, a failover occurs
Sleep For (Seconds): The interval before failover occurs after a connection fails
Primary server hosts, ports, and number of connections
Secondary server hosts, ports, and number of connections
In a multi-process environment, many processes may poll the Identity Server. For example, if 100 processes are running, each process could result in an update to the webpass.xml file. However to eliminate any possible overload, Oracle Access Manager ensures that only one process can acquire the poll tracking information for a particular time. If any configuration changes are detected, the webpass.xml file is updated for the specific time.
Beginning with Patchset 1, 10g (10.1.4.2.0), administrators can configure the PollTrackingRefreshInterval parameter in the webpass.xml file. The process that acquires the poll-tracking information triggers an update to the webpass.xml file only if one or more configuration specifications have changed in the directory. Otherwise, the process compares the last webpass.xml file time stamp to the current webpass.xml file time stamp.
A time stamp difference indicates that an administrator has modified the webpass.xml file. In this case, the process reads the PollTrackingRefreshInterval parameter and waits until the next interval specified by the value. All other processes read the webpass.xml file on the host computer and wait until the next interval specified by the the PollTrackingRefreshInterval parameter value.
The polling interval is not specific to any Web server. However, the impact of the interval that is specified using this parameter is more obvious and advantageous with multi-process Web servers such as Apache.
Setting the PollTrackingRefreshInterval parameter to an interval greater than 60 seconds ensures that the Identity Server obtains the latest configuration information, and enables the directory server and webpass.xml file to remain in sync. Increasing the value to an interval greater than 60 seconds eliminates repititious Identity Server updates to webpass.xml and eliminates the need for numerous Web server restarts.
The PollTrackingRefreshInterval parameter is shown below as it appears in the webpass.xml file. You may specify a value as high as you like (up to 32767 seconds, approximately 9 hours). However, a large value may result in a WebPass that does not remain in sync with configuration changes made using the System Console and recorded in the directory.
<SimpleList>
<NameValPair ParamName="PollTrackingRefreshInterval" Value="60" />
</SimpleList>
This parameter cannot be configured using the Identity System Console. There is no explicit indication of a change in the PollTrackingRefreshInterval value. However, you can verify the behavior by setting LOGLEVEL_DEBUG1 in the oblog_config_wp.xml file. A message is logged each time the WebPass waits for the poll tracking interval. For more information about logging configuration, see Chapter 10.
To update the WebPass poll tracking refresh parameter
Locate the webpass.xml file in the WebPass Web component installation directory. For example:
oam1014\webcomp\nsapi\identity\oblix\apps\webpass\bin\webpass.xml
In the path name, oam1014\webcomp\nsapi refers to the directory where the Oracle Access Manager WebPass for a Sun (formerly Netscape/iPlanet) Web server is installed. This portion of the path name is also known as WebPass_install_dir.
Open the file in an editor and change the PollTrackingRefreshInterval as desired. For example:
<SimpleList>
<NameValPair ParamName="PollTrackingRefreshInterval" Value="180" />
</SimpleList>
Save the file.
The parameter takes affect immediately, based on the value of the interval that you set. No reconfiguration or restart of the Identity Server or the Web server is required.
Password policies consist of a set of rules that govern the kinds of passwords that users create and the validity period for passwords. Password policies also govern how users are notified of password expiry, how users reset expired passwords, and how users retrieve lost passwords.
You create password policies in the Identity System. These policies apply to users who try to log in to the Identity and Access Systems. These policies also apply to users who try to access resources protected by the Access System, as described in "Implementing Password Policies in the Access System".
Password policies control the characteristics and life cycle of a password, including the following:
Rules for legal passwords.
This includes the minimum number of characters that can be used in a password and what types of characters must be used. For example, you can require both numbers and letters.
You configure password properties from the Identity System Console.
If you want to define additional rules for forming a legal password, an Identity Event API provides an external hook for password policy implementation. See the Oracle Access Manager Developer Guide for details.
Challenge phrases and responses for lost password management.
You can require users to respond to one or more challenge phrases when retrieving a lost password. You can also configure rules for challenge phrases, for example, you can prevent users from providing the same response to more than one challenge. Upon successfully responding to the challenge phrase or phrases, the user is redirected to a password reset page. After resetting the password, the user is logged in.
Settings for password expiry and password reset.
You can specify a password validity period and notify users of pending password expiration through email or at login time. You can also configure a URL redirect to return users to the originally requested resource after resetting a password.
Account lockout after incorrect password entry.
You can configure how many times a user can enter an incorrect password in a particular time interval before being locked out.
For the Access System, you can also configure a lockout URL that has no user ID or requested resource information.
stylesheets for password reset and lost password management pages.
Although the Access System can redirect users to these pages, the pages themselves reside on the Identity System. You can configure different Identity System-provided stylesheets for these pages.
Unique password policies for individual domains in the directory.
You can create separate sets of password policies for different branches of the directory tree.
Logs of the most recent successful and unsuccessful login attempts.
These are easily accessed logs written to the directory. They are provided in addition to the historical data provided in the audit logs.
This section discusses the following topics:
You can configure different password policies for different domains. A domain is an area under a particular node in the directory tree.
A user can qualify under more than one policy in a domain. In this situation, password policies are evaluated in a bottom-to-top order. The first policy that applies to the user is selected, as illustrated in Figure 7-1.
In this example, four password policies apply to John Smith. Password Policy 4 is implemented because it is at the lowest (cn) level of the directory tree, so it is evaluated first.
You configure password policies in the Identity System Console. You can create default password policies that apply to all domains. You can also define password policies for specific directory domains, and you can define multiple policies within a domain.
This section discusses the following topics:
You view password policies from the Password Policy Management page.
To view a list of password policies
From the Identity System Console, click the System Configuration sub-tab.
Click Password Policy in the left navigation pane
Click the policy's link to view its settings.
The Password Policy Management page appears. This page displays default password policies and a list of domain-specific password policies.
You can set defaults for password policies. These defaults include URLs that direct users to a password change page, a password expiry warning page, and a custom account lockout page. These defaults are overridden by any domain-specific policies that you create.
You can create defaults for the following:
Password expiry warning URL: This applies only to resources protected by the Access System.
This URL directs the user to an expiry notice form. Optionally, this URL can also redirect the user to a password change form. Another option for this URL is to return the user to the originally requested resource after the password has been changed.
See "To set up a default password expiry warning redirect URL" for details.
Password change redirect URL: This setting applies only to resources protected by the Access System.
It is similar to the password expiry warning URL. This URL points to a password change page. Optionally, this URL can redirect the user to the originally requested resource.
See "Configuring Redirection to a Password Reset Page After Password Expiry" for details.
Lost password redirect URL: To be useful as part of your password management system, this URL must exist as a portal insert on a Web page.
In the Identity System Console, you record this URL for informational purposes.
See "Lost Password Management" for details.
Custom account lockout redirect URL: This URL is applicable only to resources protected by the Access System.
See "Setting Up Redirect URLs for Account Lockout" for details.
By default, the Identity Server has a mechanism for displaying lockout information. If you want to customize account lockout behavior, the Identity System also returns an error code that you can use in an IDXML program. See the Oracle Access Manager Developer Guide for details.
Successful authentication events: This writes the time of the user's latest successful login attempts to the user directory server.
By default, the information is written to the oblastSuccessfulLogin attribute of the OblixPersonPasswordPolicy object class. This feature enables quick access to the most relevant login information. Historical information is provided in the audit logs.
Unsuccessful authentication events: This writes the time of the user's last failed login attempts to the user directory server.
By default, the log authentication information is written to the oblastFailedLogin attribute of the OblixPersonPasswordPolicy object class. This feature enables quick access to the most relevant login information. Historical information is provided in the audit logs.
To create the default or global password policy
From the Identity System Console, click the System Configuration sub-tab.
In the left navigation pane, click Password Policy.
The Password Policy Management page appears.
Enter the following information:
Lost Password Redirect URL: This is the URL that points users to a lost password management page in the Identity System. When entered in this field, this URL is for informational purposes only. The actual URL is provided in a portal insert. See "Lost Password Management" for details.
Password Change Redirect URL: This is a URL to a password change form. See "Configuring Redirection to a Password Reset Page After Password Expiry" for details.
Password Expiry Warning Redirect URL: Enter the URL to the password expiry warning form. See "Setting Up Password Expiry Warning Redirect URLs" for details.
Custom Account Lockout Redirect URL: Enter the URL to a lockout notification page. See "Setting Up Redirect URLs for Account Lockout" for details.
Set the logging of authentication attempts as follows:
Successful Attempts Attribute: By default, this value is oblastSuccessfulLogin. This is the recommended value. To change this value, enter any string attribute of the Person object class, or any string attribute of an auxiliary class that is attached to the Person object class.
Failed Attempts Attribute: By default, this value is oblastFailedLogin. This is the recommended value. To change this value, enter any string attribute of the Person object class, or any string attribute of an auxiliary class this is attached to the Person object class.
Click Enable to enable the logging features.
Click Save.
You can configure password policies for specific domains. These settings override any global defaults. These policies include password rules, password redirect URLs, and so on.
In a policy for a specific domain, you also can customize the appearance of the the lost password and change password pages that are presented to a user. The default stylesheets for these pages are stored in the following folder:
Identity_install_dir/identity/oblix/lang/language_id/style0
Where Identity_install_dir is the directory where the Identity Server is installed and language_id is the directory where the language pack that is being used. The default language pack is en-us, and the default stylesheets are located in the "classic style" folder named style0.
The files lpm_cr.xsl and lpm_changepwd.xsl are the original stylesheets. You can copy these stylesheets, customize them, and place the files in the currently active style folder. You also modify the relevant password policy to indicate the relative path of the XSL file in the active style folder. After configuring the new password policy, the Identity System applies the custom stylesheet for the custom password policy. The Identity System uses the default stylesheet for all other password policies.
See "Configuring Styles for Identity System Applications" for details. Also see the Oracle Access Manager Customization Guide.
In the following procedure, the Defaults button at the bottom of the page populates all fields except the Password Policy Name, Password Policy Domain, and Password Policy Filter field.
From the Identity System Console, click the System Configuration sub-tab, click Password Policy in the left navigation pane, then click Add in the Password Policy Management page.
In the Password Policy Name field, type the name of your policy.
In the Password Policy Domain field, type the domain of the LDAP directory to which this policy applies. For example:
ou=corporate,o=company,c=us
In the Password Policy Filter field, you can optionally add an LDAP filter to further define the part of the domain to which this password policy applies.
For example, (title=System Administrator) would restrict this password policy to a subset of people.
In the Lost Password Policy list, select the name of the lost password policy that you want to implement.
See "Lost Password Management" for details. If you leave this field blank, a single challenge-response model is used.
In the Password Minimum Length field, type the minimum number of characters the password must have.
The default is 8.
In the Minimum Number of Uppercase Characters field, type the minimum number of uppercase characters the password must have.
The default is 2.
In the Minimum Number of Lowercase Characters field, type the minimum number of lowercase characters the password must have.
The default is 2.
In the Minimum Number of Nonalphanumeric Characters field, type the minimum number of nonalphanumeric characters the password must have.
A nonalphanumeric character is any printable character that is not a letter or a number. Examples are +,!, and @.
The default is 1.
In the Minimum Number of Numeric Characters field, enter the minimum number of numeric characters the password must have.
If external rules apply to this password policy, check Externally specified validation rules.
Oracle Access Manager provides an external hook for password policy implementation. See Oracle Access Manager Developer Guide for details.
In the Password Validity Period field, select one of the options:
Password Never Expires.
Number of Days in which Password expires: Enter the number of days this password is valid. There is no default. You must supply a value if you select this option.
In the Password Expiry Notice Period, specify the number of days prior to password expiration that users are notified.
In the Mode of Conveying the Expiry Notice field, select one or both options:
At Login—When users log in, a message informs them of the number of days remaining until their password expires.
If the Identity System is protected by the Access System, you must enter a Password Expiry Warning Redirect URL. See "Setting Up Password Expiry Warning Redirect URLs" for details.
E-mail—Users are notified through email of the number of days remaining before their passwords expire. You cannot customize the message.
In the Password Minimum Age field, enter number of days the password must last before users can change it.
Select Change on Reset if you want to force users to change the password the first time they log in to the system after an administrator resets the password.
By default, the Change on Reset flag is not set. During self-registration, the Change on Reset flag is not set.
This field is applicable to both the Identity and Access Systems. For the Access System only, you can also configure a redirect URL for password change. See "Configuring Password Redirect URLs" for details.
In the Password History field, indicate whether or not you want to maintain a password history.
Select Do not Keep Password History or enter the number of passwords to be saved for each user. Saved passwords are stored in the directory and cannot be re-used. The default is 5.
Oracle Access Manager can determine the latest passwords saved in the directory. If you delete one, Oracle Access Manager determines which remaining one is the oldest.
In the Number of Login Tries Allowed field, specify the number of login attempts allowed before the user's account is locked.
The default value is 3. This means that if a user attempts to login three times using an incorrect login credential, they will be locked out after the third attempt that occurs within the lockout interval specified by "Lockout Duration value". An incorrect login credential consists of a correct username but incorrect password. During the lockout interval, the user cannot login even with correct credentials.
Note:
This also applies to the number of attempts for a challenge response during Lost-Password Management.In the Lockout Duration field, specify the number of hours an account remains locked after a user exceeds the number of failed logins specified in the previous step.
The default is 24 hours. To clear a lockout before the lockout duration expires, an administrator can reset the user's password from the Identity System. Upon login the user is redirected to a page where he or she can choose a new password—if Change on Reset was selected in the Password Policy Management page before the administrator reset the password.
If Change on Reset was not selected when the administrator assigned a new password, the user can log in to the system with the administrator-assigned password.
In the Login Tries Reset field, specify the number of days to store the failed login attempts that are uninterrupted by a successful login.
For example, if this value is set to 3, and a user fails to log in once, the application keeps track of that failure for 3 days before clearing it.
In the Lost Password Redirect stylesheet, you can optionally enter a relative path to an XSL stylesheet.
For example, if the stylesheet file is located in Identity_Server_installdir /identity/oblix/lang/en-us/style0/myStyleSheet.xsl, you would enter /myStyleSheet.xsl.
See the Oracle Access Manager Customization Guide for details on stylesheet configuration. See "Lost Password Management" for details on lost password redirection.
If you leave this field blank, the default stylesheet is used.
In the Password Change Redirect stylesheet you can optionally enter a relative path to an XSL stylesheet.
For example, if the stylesheet file is located in Identity_Server_installdir /identity/oblix/lang/en-us/style0/myStyleSheet.xsl, you would enter /myStyleSheet.xsl.
See the Oracle Access Manager Customization Guide for details on stylesheet configuration. See "Configuring Redirection to a Password Reset Page After Password Expiry" for details on the change password form.
If you leave this field blank, the default style sheet is used.
In the Password Expiry Warning Redirect URL, you can optionally specify a URL to override the default.
This applies only to the Access System. See "Setting Up Password Expiry Warning Redirect URLs" for details on this URL.
In the Custom Account Lockout Redirect URL, specify the redirect URL for users who have exceeded the number of login attempts.
This applies only to the Access System. See "Setting Up Redirect URLs for Account Lockout" for details.
Select Password Policy Enable to enable this password policy.
If you later change the setting of this field or make any other change to this password policy, you have to flush the password policy cache. You can flush the password policy cache in the Access System Console. From the Access System Console, click Common Information Configuration, and click the Flush Password Policy Cache tab. For more information, see Oracle Access Manager Access System Administration Guide.
Click Save to save this policy and return to the Password Policy Management page.
The new policy appears in the list on the page.
Note:
The Redirect URLs shown on this page apply to the Access System. For more information, see "Implementing Password Policies in the Access System".During this operation, you can click the Defaults button to populate all fields with default values, except the Password Policy Name, Password Policy Domain, and Password Policy Filter. See "Order of Password Policy Evaluation" for information about each parameter.
To modify a password policy's parameters
From the Identity System Console, click the System Configuration sub-tab, then click Password Policy in the left navigation pane.
The Password Policy Management page displays a list of password policies.
In the Password Policy Management page, click the policy you want to modify.
The page with the policy's parameters appears.
Modify the parameters as necessary.
Click Save.
The Password Policy Management page displays a list of password policies. Saved passwords are stored in your LDAP directory. Oracle Access Manager can determine the latest passwords. If you choose to delete one, Oracle Access Manager determines which is the oldest.
From the Identity System Console, click the System Configuration sub-tab, then click Password Policy in the left navigation pane.
In the Password Policy Management page, select the check box next to the policy you want to delete.
Click Delete.
Click OK when prompted to confirm your deletion.
Lost password management enables users to reset their passwords if they forget them. Lost password management is a process that consists of the following:
An "I lost my password" link that directs users to a page where they can respond to challenge phrases.
You implement lost password management by creating a URL to a lost password management page, and placing this link on Web pages where you want users to be able to access this functionality. These URLs are known as portal inserts. See the Oracle Access Manager Customization Guide for details.
A lost password management page that contains challenge phrases and response fields.
The lost password management URL routes the users to an Identity System page that contains one or more challenge questions.
A password reset page that is displayed if the user answers the challenges correctly.
After giving the correct response, users can set a new password in the Identity System.
Additional functionality to allow the user to be redirected back to the originally requested page.
For record-keeping purposes, you record the lost password management URL in a password policy in the Identity System Console. You can configure a lost password management policy for a particular domain.
The Identity System encrypts response values using an encryption scheme licensed from RSA. This encryption scheme is different from secure hash algorithm (SHA). You can replace the default encryption with your own by writing a custom action using the Identity Event Plug-in API. This is useful if you have existing challenge and response attributes that you want to import into the Identity System. See the Oracle Access Manager Developer Guide for details.
Lost password management is enabled by default.
Note:
Unlike other redirect URLs that you enter in the Identity System, you enter the lost password management redirect URL for informational purposes only. Its primary location is in the portal insert.Task overview: Implementing Lost Password Management
In your directory, create two new attributes: one to be used for challenges that are presented to users, and one for responses that users provide to the challenges.
To support lost password management, you define an attribute pair to store values for challenges that are presented to users and for responses to those values. For example, you can define a pair of attributes named Challenge and Response. From the Identity System Console, you assign the Challenge and Response semantic types to these attributes. See "To configure challenge and response-type attributes in your directory" for details.
From the Identity System Console, modify the attributes in your Person object class.
Configure the attribute that is to store the challenge phrases, and the attribute that is to store the user's responses to the challenge phrases.
See "To configure the Lost Password Management attributes" for details.
From User Manager, configure attribute access controls for these attributes.
To be able to view and view and modify challenges and responses on profile pages, users need read and modify rights for the challenge and response. See "Allowing Users to View and Change LDAP Data" for details.
Add the challenge and response attributes to user profile pages so that they appear when users view or modify these pages.
During lost password management, users are directed to a page that presents them with challenge phrases. The page that contains the challenge phrases and response input fields is a profile page that you configure in the User Manager. See "Configuring Tab Profile Pages and Panels" for details. Note that users can configure challenges during login, even if the associated attributes have no "self" read or modify rights.
Configure workflow step pages to use these attributes.
The challenge phrases and responses need to be configured during self-registration so that they can be used later for password retrieval. It is less likely, but possible, that a Create User workflow could also be useful to enable participants in the workflow to configure challenge phrases for new users. See "Chaining Identity Functions Into Workflows" for details. The workflow step page does not require read or write permissions for challenge parameters.
Configure lost password management policies from the Identity System Console.
See the "Managing Password Policies" for details.
Insert a lost password management URL in a third-party application or portal page.
See the information in this section for details. Also see the information on portal inserts in the Oracle Access Manager Customization Guide.
The format of a lost password management URL is as follows:
http://machinename:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_mgmt.cgi?program=passwordChallengeResponse&login=%scheme1_uid_parameter_value%%scheme2_uid_parameter_value%%schemeN_uid_parameter_value%&target=top
This is similar to a password expiry reset URL, as described in "Configuring Redirection to a Password Reset Page After Password Expiry". One difference between the two types of URL is the following parameter:
program=passwordChallengeResponse
Another difference is that if you supply variables such as the user ID on this URL, you will need to modify the corresponding cgi script to pass in the user's login ID. Alternatively, you can use the following URL syntax and require the user to re-enter a user ID after being redirected to the lost password reset page:
http://machinename:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_mgmt.cgi?program=passwordChallengeResponse&target=top
In the preceding URL, lost_pwd_mgmt.cgi is provided with Oracle Access Manager.
Lost password management can be configured as either a single or a multiple challenge-response system. Challenge-response pairs are displayed in the following locations:
During a create user account workflow, a workflow step will contain entries for challenge and response attributes.
On View and Modify Profile pages, challenge and response pairs are displayed.
During lost password management, users must respond to one or more challenge phrases.
When logging in to Oracle Access Manager, users are prompted to provide additional challenges if the configured number of challenges is lower than the number required in the lost password policy that applies to the user.
In addition to providing challenge and response prompts on the lost password management page, you may want to provide additional information on the page. For example, you may want to configure a link (or a workflow step) that sends the user to the password reset page after the user successfully responds to the lost password management challenges.
If a lost password management policy applies to the user, when the user clicks the lost password management URL, multiple challenges and response fields are displayed. The number of challenges that the user sees is determined by the Minimum Challenges to be Answered field. See "To configure lost password management for a password policy domain" for details.
As noted in "Creating Password Policies for a Specific Domain", password policies apply to particular domains or groups of users. If no lost password policy applies to a user, only one challenge phrase and one response entry field are displayed. If multiple challenge and responses are configured, but no lost password policy applies to a user, the first configured challenge phrase and response are displayed.
Users are prompted to configure additional challenge phrases during login if the number of configured challenge phrases and responses falls short of the minimum configured in the lost password policy. For example, suppose that you increase the minimum number of challenges to be configured after establishing the initial lost password management policy. In this case, during login the user is presented with an additional challenge phrase, displayed as one of the following:
A text box: This appears if the User setting was selected in the lost password management policy.
A select box with predefined phrases: This appears if the Predefined setting was selected in the lost password management policy.
A combo box with predefined phrases: This appears if the User or Predefined setting was selected in the lost password management policy.
See "To configure lost password management for a password policy domain" for details.
If you change the source type in the lost password management policy, for example, if you change the source from User to Predefined, or you change the minimum length, or change the Allow Duplicate Responses flag, these changes are enforced when the user modifies his or her own profile.
When being prompted to configure additional challenges, the type of message that the user receives depends on what has changed in the lost password management policy. For example, suppose that you change the minimum length of a response from 3 characters to 8 characters. When the user tries to save a change to his or her profile, an error message, "response does not meet the minimum length requirement" appears. If you increase the minimum number of challenges in the policy, the user is prompted to supply the required information during login.
The following procedures describe how to configure lost password management.
Note:
You cannot delete challenge parameters from profile or workflow pages if there is a lost password management policy in effect.To configure challenge and response-type attributes in your directory
Ensure that there are two unused, empty attributes in your directory to be used for user challenges and responses.
If two appropriate attributes are available, continue to the following procedure.
If you need to add new attributes, you can do so using whatever method you prefer.
The following is an example of creating an LDIF schema file with a new auxiliary object class and two new attributes. You could create attributes that are similar to the following using the syntax appropriate for your directory server type:
# ----------- Attributes --------------- # dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.9999.1.1094.204 NAME 'Challenge2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.9999.1.1094.205 NAME 'Response2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # ----------- Object class --------------- # dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.9999.1.1094.206 NAME 'oblixAuxPerson4LPM' DESC 'User defined objectclass' SUP top AUXILIARY MAY ( Challenge2 $ Response2 ) )
Import the LDIF file into the directory.
To configure the new auxiliary object class in Oracle Access Manager, in the Identity System Console, click Common Configuration.
Click Object Classes in the left navigation pane.
Click Add.
Select the name of the new object class from the list.
Select the option button for the Person structural object class.
The new auxiliary object class is now associated with the Person structural object class. You can now configure the new challenge and response-type attributes in this object class, as described in "To configure the Lost Password Management attributes".
To configure the Lost Password Management attributes
To configure an attribute from your Person object class to store the challenge phrases, from the Identity System Console, click Common Configuration.
Click Object Classes in the left navigation pane.
Click the link for the Person object class.
Click Modify Attributes.
In the Attribute list, select the attribute that you want to use for the challenge phrase.
This must be a new, empty attribute.
Configure the following.
See "About Object Class Attributes" and "Configuring Attributes" for details:
Set the Semantic Type of this attribute to Challenge.
Set the Data Type to case-insensitive string.
Set the Attribute Value(s) field to Single
The Display Type is configured automatically, depending on the type of policy you configure.
Assign an appropriate Display Name, for example, Challenge.
If you configure multiple challenge phrases, these are stored as a single value in the user's directory entry for the challenge attribute. The values are stored in encoded format.
From the Attribute list, select a second attribute from your Person object class to store the user's responses to the challenge phrases.
This must be a new, empty attribute.
Configure this attribute as follows.:
Set the Semantic Type of this attribute to Response.
Set the Data Type to case-insensitive string.
Set the Display Type to Password.
Set the Attribute Value(s) field to Single.
Assign an appropriate Display Name, for example, Response.
See "About Object Class Attributes" and "Configuring Attributes" for details:
If you configure multiple challenges and responses as part of your lost password management policy, the values that the user provides for the responses are stored as a single value in the user's directory entry for the response attribute. The values are stored in encoded and encrypted format.
Add these attributes to user profile pages or workflow step panels, depending on where you want them to be displayed.
To view lost password policies
In the Identity System Console, click the System Configuration sub-tab, then click Lost Password Policy in the left navigation pane.
In the Lost Password Policy Management page, click the link for the policy that you want to view.
To enable or disable Lost Password Management
Locate the oblixbaseparams.xml file.
The default path for the file is as follows:
IdentityInstall_dir/identity/oblix/apps/common/bin/oblixbaseparams.xml
where IdentityInstall_dir is the directory where the Identity System is installed.
Make sure Yes is entered for the Apply_LostPwdMgmt parameter.
Yes is the default. Otherwise type No to disable this feature.
Save and close the file.
To configure lost password management for a password policy domain
From the Identity System Console, click the System Configuration sub-tab, then click Lost Password Policy.
In the Lost Password Policy page, click Add.
The Add Lost Password Policy Page appears.
In the Lost Password Policy Name field, enter a name.
Note that for environments that use Oracle Internet Directory, this name cannot contain any special characters.
For Challenge Phrase Source, select who is to provide the challenge phrase:
User: When creating an account, the user must supply the challenge phrases.
Predefined: When creating a user account, a list of predefined challenges are shown to the user. The user must select from among the supplied challenge phrases.
User or Predefined: When creating a user account, a list of predefined phrases are shown to the user. The user can either select from among the supplied challenge phrases, or supply new challenge phrases.
In the Predefined Challenge Phrases field, enter a challenge phrase and click Add.
The phrase is added to a selection list. Use the Delete button to remove selected phrases from the list.
After completing the definition of this lost password policy, you can add predefined challenge phrases or delete existing ones at any time.
In the Minimum Challenges to be Configured field, enter the number of challenges that are to be configured when creating the user account or modifying the user profile.
In the Challenge Response Minimum Length field, enter the minimum number of characters permitted in the responses that a user configures.
The Allow Duplicate Responses checkbox configures the following:
Unchecked: False. If the user provides the same response for more than one challenge phrase, an error is displayed.
Checked: True. Turns off duplicate checking.
In the Minimum Challenges to be Answered field, enter the number of challenges that you want the user to respond to when resetting the password using the lost password management application.
This value must be the same or less than the one in the Minimum Challenges to be Configured field. For example, if you set the value of this field to 3 and you configure four challenge-response pairs, the user must respond to three challenges. Note that the actual number of responses that the user must provide depends on the number of correctly configured challenges and responses as well as the value of this field. For example, if you enter 2 in this field, but only one of the two challenge-response pairs is configured correctly, the user is prompted to respond to only one challenge.
In the Challenge Pose Type field, select whether challenges are to be displayed all at once or sequentially.
All at once: Challenges are displayed at one time. The order in which they are displayed changes each time. The user must respond correctly to all challenges.
One after the other: The user must respond to one challenge phrase before the next is displayed.
Select the Send Email After Password Change box if you want email to be sent to the user after the password has been reset.
By sending email to the user, if an intruder has reset the password, the user can notice that something unexpected has happened and can contact the administrator.
Select the Lost Password Policy Enable box if you want administrators to be able to use this policy.
Click Save.
Add the name of this policy to a password policy domain.
See "Creating Password Policies for a Specific Domain" for details.
You can apply the password policies configured in the Identity System Console to resources that the Access System protects. To do this, you modify the authentication scheme that protects those resources. When users authenticate to a resource protected by the Access System, the password policy is invoked for the users if they are in the password policy domain.
The rest of this section discusses the following topics:
Modifying Authentication Schemes to Include a Password Policy
Configuring Redirection to a Password Reset Page After Password Expiry
See the section "Order of Password Policy Evaluation" for more information. See the Oracle Access Manager Access System Administration Guide for instructions on creating an authentication scheme.
The following procedure describes how to modify an authentication scheme to include a password policy.
To modify an authentication scheme to include a password policy
Log in to the Access System.
From the Access System Console, click Access System Configuration and then click Authentication Management in the left navigation pane.
The Authentication Management page appears, listing all the configured authentication schemes.
Click the link for an authentication scheme you want to change, and then click the Modify button on the page that appears.
The Modify Authentication Scheme appears.
Choose the validate_password plug-in, add the following information to the Plugin Parameters field, and click Save:
obReadPasswdMode="LDAP",obWritePasswdMode="LDAP"
For example, suppose the original validate_password Plugin Parameters statement for the Basic Over LDAP scheme was the following:
obCredentialPassword="password"
The new parameter set would be as follows:
obCredentialPassword="password",obReadPasswdMode="LDAP", obWritePasswdMode="LDAP".
The new parameters must be added for password change redirection.
If the WebPass and WebGate reside on different servers, choose the validate_password plug-in and add the obWebPassURLprefix parameter in the Plugin Parameters field, as follows:
http://webpasshost:webpassport
Where webpasshost and webpassport are the host and port for the server where the WebPass resides.
Make a note of the uid parameter value for the credential_mapping plug-in.
You need this value when creating the password change redirect URL. For example, the uid parameter value may be %userid%.
Repeat this process for all authentication schemes for which you want to set up password change redirection.
Note:
If you make any change to the password policy, be sure to flush the Access Server cache. See "Updates to the Access Server Cache" for more information.You can configure URLs that redirect users to the following pages:
To a password reset page
To a password expiration warning page
To an error page stating that the user account is locked.
These redirect URLs apply only to cases where users log in to resources that are protected by a WebGate or AccessGate. In other words, if you have protected a resource as described in Oracle Access Manager Access System Administration Guide, you can configure one of these URLs. You can also configure these URLs to return the user to the originally requested resource when they are done with the target page specified in the redirection URL.
These URLs are explained in the following sections:
When a password has gone beyond the validity period that you configured in a password policy, when the user attempts to log in, he or she is automatically redirected to a password reset page. You can configure the URL to this password reset page. Optionally, the password reset URL can redirect the user back to the originally requested resource after the password is reset.
To enter a password change redirect URL
From the Identity System Console, click the System Configuration sub-tab, then click Password Policy in the left navigation pane.
The Password Policy Management page displays a list of password policies.
In the Password Change Redirect URL field, enter a URL with the following syntax:
http://machinename:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_mgmt.cgi?program=redirectforchangepwd&login=%scheme1_uid_parameter_value% %scheme2_uid_parameter_value%%schemeN_uid_parameter_value% &target=top
Where:
machinename:portnumber are the host and port of the Web server on which a WebPass is installed, and
%scheme1_uid_parameter_value% %scheme2_uid_parameter_value%%schemeN_uid_parameter_value% is the string of uid parameter values for all the authentication schemes for which you want to set up password change redirection
For example, suppose that you have the following credential_mapping plug-in parameters for two authentication schemes:
Form over LDAP—obMappingBase="o=company,c=us", obMappingFilter="(&(objectclass=genSiteOrgPerson) (uid=%login%))"
Basic over LDAP—obMappingBase="o=company,c=us", obMappingFilter="(&(objectclass=genSiteOrgPerson) (uid=%userid%))"
The password change redirect URL that corresponds to these parameters would be the following:
http://machinename:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_mgmt.cgi?program=redirectforchangepwd&login=%login%%userid%&target=top
To return the user to the originally requested resource after submitting the password change form, you can code a BackURL statement in the query string for this URL. The basic syntax is:
http://machinename:portnumber/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_mgmt.cgi?prtforchangepwd&login=%login%%userid%&backURL=%HostTarget%%RESOURCE% &target=top
For example:
http://130.35.46.141:99/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_mgmt.cgi?login=%login%%userid%&backUrl=%HostTarget%%RESOURCE%
At runtime, the URL of the originally requested resource is substituted for the values enclosed in the percent delimiters, for example:
http://130.35.46.141:99/identity/oblix/apps/lost_pwd_mgmt/bin/lost_pwd_mgmt.cgi?login=admin&backUrl=http://www.webserver1.com/test/a.html
The script lost_pwd_mgmt.cgi contains logic to process the query parameters. The lost_pwd_mgmt.cgi script is provided with Oracle Access Manager. It is a dynamically generated page, so no manual configuration for it is necessary.
Click Save.
You configure a password expiry period in a password policy. When a user's password is about to expire, a redirect URL sends the user to a warning page. Oracle Access Manager does not provide this warning page. You must create the actual landing page that contains the warning. Optionally, this warning page can also contain a URL that directs the user to the password reset page.
The password expiry redirect URL applies only to resources that are protected by the Access System. In other words, if you have protected a resource with a WebGate, you can configure this URL.
The password expiry URL is similar to the password change redirect URL. The URL directs the user to an expiry notice form, optionally redirects the user to a password change form, then optionally returns the user to the originally requested resource after the password is changed.
You can configure a default password expiry URL that applies to all password policies, and you can configure this URL for an individual policy.
Users may be redirected automatically to this URL, or they can be notified by email prior to expiry. See "Creating Password Policies for a Specific Domain" for details.
There is no built-in page or portal to serve as a target for this URL. You must create this page. For example, you may want to provide a page that states, "Your password will expire soon and needs to be changed."
To set up a default password expiry warning redirect URL
From the Identity System Console, click the System Configuration sub-tab, then click Password Policy in the left navigation pane.
The Password Policy Management page displays a list of password policies.
In the Password Expiry Warning Redirect URL, enter a URL with the following syntax:
http://machinename:portnumber/path-to-custom-page
Where:
machinename:portnumber are the host and port of the Web server on which a WebPass is installed, and
path-to-custom-page is the path of the custom Web page that warns them that their password is about to expire.
To return the user to the originally requested resource after authenticating, you can code a "back URL" (that is, a backURL statement) in the query string for this URL as follows:
http://machinename:portnumber/notice.cgi?prtforchangepwd&login=%login%%userid%&backURL=%HostTarget%%RESOURCE%&target=top
For example, you could enter the following URL:
http://130.35.46.141:99/cgi-bin/notice.cgi?login=%login%%userid%&backUrl=%HostTarget%%RESOURCE%
In this example, notice.cgi contains logic to process the query parameters. You can create a simple Web page, or write a cgi or another script or JSP page to parse the parameters in the URL and display appropriate messages, process timeouts, and redirect the user to the backURL.
At runtime, the actual values of the user and the originally requested resource are substituted for the query strings. For example:
http://130.35.46.141:99/cgi-bin/notice.cgi?login=admin&backUrl=http:// www.webserver1.com/test/a.html
In this example, notice.cgi is a script that you have written that contains logic to process the query parameters.
The custom page can also retrieve the expiration date using an ExpiryDate query parameter. The following is an example of this parameter:
http://130.35.46.141:99/cgi-bin/notice.cgi?ExpiryDate=%PwdExpiryDate%&backUrl=%HostTarget%%RESOURCE%
Click Save.
As with the other redirect URLs, the redirect URL for account lockout is applicable only to the Access Server. You can configure a lockout URL that has no user ID or requested resource information.
To implement account lockout redirection, you need to create a Web page, or write a cgi or another script or JSP page to parse the parameters in the account lockout URL. The script or JSP should display messages regarding account lockout, process timeouts, and redirect the user to the originally requested resource.
To set up the account lockout URL
From the Identity System Console, click the System Configuration sub-tab, then click Password Policy in the left navigation pane.
The Password Policy Management page displays a list of password policies.
In the Custom Account Lockout Redirect URL field, enter a URL for redirecting the user to an account lockout form.
Click Save.
You can ensure that the Access Server is notified of changes made by the Identity System and that the Access System's cache is flushed automatically. However, if you choose to not implement automatic cache flush, you can still manually flush the cache when you make changes to the Password Policy Management page in the Identity System. This can be useful in avoiding a significant delay in applying password-policy management changes.
For more information about flushing the Access Server caches, see Oracle Access Manager Access System Administration Guide and the Oracle Access Manager Deployment Guide.
The Access Manager SDK consists of libraries, build instructions, and examples that you use to build an AccessGate for non-Web resources. The Access Manager SDK is automatically installed with the Identity System in IdentityServer_install_dir/AccessServerSDK.
The following functions in the Identity System require the Access Manager SDK. You must manually configure the Access Manager SDK for these functions:
Automatic cache flush between the Identity System and Access System
Automatic login to the Access System after self-registration.
Complete the following procedure if you protect WebPass with a WebGate. You do not have to repeat the procedure for each Identity System function previously mentioned.
To configure the Access Manager SDK
Install and set up the Identity System and Access System, as described in the Oracle Access Manager Installation Guide.
Note:
The Access Manager SDK is installed automatically with the Identity System in IdentityServer_install_dir/AccessServerSDK.Windows: Set your path to point to the Access Manager SDK by modifying the systems PATH variable as shown below:
set PATH = %PATH%;Identityserver_install_dir\AccessServerSDK\oblix\lib
From the Access System Console, click Access System Configuration, AccessGate Configuration.
Add an AccessGate.
You do not need to configure a port.
The Identity System uses the AccessGate to communicate with the Access Server for purposes of flushing the cache.
For more information about flushing the Access Server caches, see Oracle Access Manager Access System Administration Guide and the Oracle Access Manager Deployment Guide.
Select Off for Access Management Service if you have upgraded your WebGates.
A value of On is only appropriate for legacy systems.
Save the AccessGate.
Access the IdentityServer_install_dir/identity/AccessServerSDK/oblix/ tools/configureAccessGate directory and run the configureAccessGate script.
Where IdentityServer_install_dir is the directory where the Identity Server is installed.
See the Oracle Access Manager Access System Administration Guide for details about modifying an AccessGate.
When running configureAccessGate, ensure that the AccessGate ID is the same as the AccessGate name you entered from the Access System Console in step 3.
From the IdentityServer_install_dir/identity/oblix/data/common directory, open the basedbparams.xml parameter catalog file in a text editor.
Change the value of the doAccessServerFlush flag to true as follows:
<NameValPair ParamName="doAccessServerFlush" Value="true" />
Restart the Identity Server
Instead of using the command line or the installation GUI to install a Oracle Access Manager component, you can automatically install a component by cloning the configuration of an already-installed component. Cloning creates a copy of a component on a remote system using an already-installed component as a template.
Synchronizing enables you to harmonize two installations of the same component when one is more up-to-date than the other. Synchronization can be used to upgrade or repair installations on similar platforms.
See the Oracle Access Manager Installation Guide for details.
