| Oracle® Access Manager Integration Guide 10g (10.1.4.2) Part Number E10356-01 |
|
|
View PDF |
| Oracle® Access Manager Integration Guide 10g (10.1.4.2) Part Number E10356-01 |
|
|
View PDF |
Oracle provides components that interface with RSA Security products to provide native RSA SecurID® authentication for Oracle Access Manager-protected resources. This chapter introduces SecurID authentication and the components, requirements, and processes needed to successfully integrate SecurID authentication with Oracle Access Manager 10g (10.1.4.0.1).
Oracle Access Manager integrates with RSA components to provide SecurID authentication.
RSA SecurID authentication is based on two factors: something the user knows and something the user has.
Something the User Knows: This is a secret personal identification number (PIN), similar in concept to a personal bank code PIN. In this case, the PIN may be system generated or personally chosen and registered with the RSA ACE/Server®, which has been renamed to the Authentication Manager.
Something the User Has: This is the current code generated by a hand held device known as a token. Oracle Access Manager supports all RSA SecurID tokens including RSA SecurID Standard Card, Key Fob, PINPAD Card, and a software-based security token (SoftID) that resides on a user's computer.
The random unpredictable code generated by the token is known as a tokencode. Together, the user's PIN and the SecurID tokencode become the user's Passcode.
The following components are needed for the integration:
See also, "Integration Summary".
You can find support and certification information at the following URL:
http://www.oracle.com/technology/documentation/
You must register with OTN to view this information.
Also, you can see the supported versions and platforms for this integration on Metalink, as follows.
To view information on Metalink
In your browser, enter the following URL:
Log in to MetaLink.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Identity Management and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, Oracle Access Manager Certification to display the certification matrix.
During the SecurID authentication process, users must submit their username and passcode using an HTML form. The RSA ACE/Server authenticates the identity of each user through a computer that is registered with the ACE/Server as a client (ACE/Agent). In this case, one Oracle Access Manager SecurID Access Server must be registered and set up as an ACE/Agent. See "Oracle SecurID Access Server and ACE/Agent Requirements" for more information.
Note:
While the RSA ACE/Server has been renamed to the RSA Authentication Manager, this chapter uses the original naming convention.The RSA ACE/Server compares the tokencode it has generated with the tokencode the user has entered. Tokencodes change at a specified interval, typically 60 seconds. Time synchronization ensures that the tokencode displayed on a user's token is the same code the ACE/Server software has generated for that moment. Authentication is successful when the tokencodes match.
Two-factor authentication provides stronger legal evidence of who performed the task. When properly implemented, the ACE/Server tracks all login requests and operations to reliably identify the user who is responsible for each logged action. For example, see the administration documentation for RSA 5.1 for details about RSA audit trail reports, the automated log database feature, and monitoring activity in real time.
Oracle Access Manager enables integration of SecurID authentication by providing the following:
The HTML forms required for SecurID authentication operations
The CGI script required to authenticate users with the RSA ACE/Server
The SecurID authentication plug-in, authn_securid, required for the Oracle Access Manager SecurID authentication scheme
Oracle Access Manager uses and supports the following RSA security features:
Two-factor SecurID authentication
RSA BSAFE® SSL-C and BSAFE® Crypto-C
RC6 encryption for cookies passed between a WebGate and the user's browser
Optional RSA Keon® Certificate Server and X.509v3 digital certificates (RSA's Keon public key infrastructure (PKI))
Note:
Oracle Access Manager supports, but does not require, certificate publishing. SecurID may be used as an authentication scheme for both Oracle Access Manager and Keon Web Passport. However, separate authentications must be completed for each product. See the appropriate implementation guide for RSA Keon Certificate Authority for your LDAP directory server.The Identity System provides the applications you need to manage users, groups, organizations, identity-based workflows, and delegated administration.
All ACE/Server users must be added to the Identity System.
Delegated Identity Administrators can create a workflow definition to add ACE/Server users to the Oracle Access Manager directory. See the Oracle Access Manager Identity and Common Administration Guide for more information.
The Access System provides policy-based authentication, authorization, auditing, and Web single sign-on. Access System components for SecurID authentication include the Policy Manager, Access System Console, Access Server, and WebGate(s), described in the following list.
The Policy Manager: The Policy Manager provides the applications for policy management, designation of resources (Web and non-Web) and policy testing. Master Access Administrators define policy domains and Delegated Access Administrators define the resources to be protected by a policy domain.
The Access System Console: Master Oracle Access Manager Administrators and Master Access Administrators use the Access System Console to define authentication schemes, including the SecurID authentication scheme required for this integration, and authorization rules that allow or deny access to resources. The Access system, host identifiers, and master audit settings are also configured in the Access System Console.
The Access Server: The Access Server receives requests from a WebGate and queries authentication, authorization, and auditing rules stored in the directory server used by Oracle Access Manager. The Access Server returns the authentication scheme, user credentials, and authorization to the requesting WebGate.
The Access Server installation includes the SecurID authentication plug-in, which is a shared library that makes outbound calls to verify the user's authentication credentials against those on the RSA ACE/Server. To accomplish this, one Access Server must be set up as an ACE/Agent. See "Oracle SecurID Access Server and ACE/Agent Requirements".
WebGate: WebGate intercepts and forwards HTTP requests for Web resources to the Access Server for authentication and authorization. The WebGate also starts the user's session, creates session cookies, and passes these to the user's browser.
The WebGate installation includes the SecurID forms and the CGI script needed to authenticate users with the ACE/Server and to support two special modes of operation. See "Next Tokencode Mode Support" and "New PIN Mode Support" for more information.
Oracle Access Manager 10g (10.1.4.0.1) integrates with SecurID ACE Server 5.0 and supports SDI encryption mode. This version is used for demonstration purposes only.
Table 14-1 summarizes Oracle Access Manager SecurID integration features.
Table 14-1 SecurID Integration Summary
| Feature | Support for the feature |
|---|---|
|
Authentication method |
Native SecurID authentication |
|
New PIN Support |
All |
|
Next tokencode support |
Yes |
|
Secondary server support |
Yes |
|
Location of node secret on Windows client |
%windir%\system32 |
|
Location of node secret on Unix client |
ACE/Agent installation directory |
|
ACE/Agent installation directory |
Net OS Agent and Unix Agent |
|
SecurID user specification |
Designated users |
|
SecurID protection of administrators |
Yes |
|
Identity System features and functions |
All |
|
Access System features and functions |
All |
Requirements for SecurID authentication are discussed in the following topics.
Note:
Oracle Access Manager does not support multiple ACE realms. The ACE Agent uses an automatic response time load balancing algorithm to determine where to send an authentication request. Such requests go to either a primary Ace Server or a replica. The automatic algorithm can be overridden by creating a manual load balancing configuration file, sdopts.rec. However manually weighting an ACE server as a server of last resort does not preclude the Agent from communicating with it. As such, a true failover setup cannot be achieved with this method. For more information, see your ACE server documentation.You can find support and certification information at the following URL:
http://www.oracle.com/technology/documentation/
You must register with OTN to view this information.
Also, you can see the supported versions and platforms for this integration on Metalink, as follows.
To view information on Metalink
In your browser, enter the following URL:
Log in to MetaLink.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Identity Management and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, Oracle Access Manager Certification to display the certification matrix.
The RSA ACE/Server software provides SecurID identification and authentication of users in the ACE/Server data directory. Data from ACE/Server user records in the directory are validated with the ACE/Server's token records. The ACE/Server's native LDAP support is separate from, yet compatible with, Oracle Access Manager.
RSA ACE/Server Installation and Configuration Requirements
The following installation and configuration must be completed before you begin SecurID integration with Oracle Access Manager.
RSA ACE/Server installation and configuration guidelines
The SecurID ACE/Server software must be installed on a supported platform.
The system time must be correct to prevent the server and client from being out of sync.
The SecurID tokens or key fobs must be installed, SecurID users must be created on the ACE/Server, and tokens must be assigned.
Each user name must be mappable through an LDAP filter to a Distinguished Name in the directory.
A user who authenticates through a RADIUS server must have a profile in the ACE/Server database that provides a list of requirements the user must meet before the ACE/Server challenges the RADIUS user for a passcode.
An ACE/Server slave and/or replicated ACE/Server can provide failover if the primary ACE/Server is down.
Setting up your RSA ACE/Server, SecurID tokens, and users is outside the scope of this manual. See the installation and administration documentation for the supported RSA ACE/Server for details and troubleshooting tips.
As discussed earlier, Oracle Access Manager supports all RSA SecurID tokens and SecurID authentication. The following modes are also supported.
During authentication, the ACE/Server may direct the user to provide the next tokencode that appears on their SecurID token to prove that they have the assigned token. This operation is known as Next Tokencode mode, which may be triggered by one of the following situations:
An incorrect Passcode was provided repeatedly during login.
When a user attempts authentication with incorrect Passcodes four consecutive times, the ACE/Server turns on Next Tokencode mode, as noted in the ACE/Server's Activity Report. The next time the user successfully authenticates with their correct Passcode, they are challenged for the next tokencode that appears on their SecurID token.
The ACE/Server requires confirmation of, or synchronization with, the token.
Even with a correct Passcode, the ACE/Server administrator may set the Next Tokencode mode On to force the user to confirm that they have the SecurID token or to synchronize the token with the ACE/Server.
When Next Tokencode mode is On, the Next Tokencode challenge form is presented to the user immediately following a successful login. See "Next Tokencode Sequence" for details.
The token may be in New PIN mode the first time the user logs in or the ACE/Server administrator may enable New PIN mode. New PIN mode requires the user to complete a sequence of forms to define, or have the system generate, a new PIN number. Table 14-2 provides a description of the New PIN forms and their functions.
Table 14-2 Oracle-Provided New PIN Forms and Functions
| New PIN Function | Description |
|---|---|
|
New PIN Query form |
Tells the user a new PIN is required. Provides instructions and fields to fill in. |
|
New PIN Confirmation form (system-generated PINs) |
Confirms the system-generated PIN for login. Redirects to the resource within 30 seconds |
|
New PIN form (user-generated PINs) |
Asks for a username, Passcode, and new PIN. |
Each PIN may be:
Four to eight alphanumeric or numeric characters
All the same length or of varying lengths
Defined by the user or by generated the system
See "New PIN Sequence" for details.
All SecurID authentication requests must be directed to a single Access Server (also known as the Oracle SecurID Access Server). The RSA ACE/Agent v5.x, formerly known as the ACE/Client, is an RSA Security program that must be installed on all installed Access Servers. However, only one Access Server may be registered as an RSA ACE/Agent to perform the authentication dialog with the RSA ACE/Server.
Access Server-compatible Web servers installed on the Operating Systems shown in "Access Server and ACE/Agent Requirements" will support RSA ACE/Agent software v5.x.
The RSA ACE/Agent software is included with the Access Server on Unix systems and must be installed manually on Windows-based Access Servers.
Oracle SecurID Access Server guidelines
All Access Servers in the installation must have the RSA ACE/Agent software installed.
One Access Server must be registered as an ACE/Agent Host on the ACE/Server and must have the RSA ACE/Agent software installed to:
Enable the Access Server to be recognized as an ACE/Server client
Manage authentication requests from the client to the ACE/Server
Enforce two-factor authentication and block unauthorized access
Provide automatic load balancing by detecting replica ACE/Server response times and routing authentication requests accordingly
See "Setting up the Access Server as an ACE/Agent" for details.
The Access Server on Windows systems must have a certificate from the same CA root as the ACE/Server. This is not needed on Unix systems.
The system time on the client must be correct to prevent the server and client from being out of sync.
At least one Access Server and one WebGate must be paired for SecurID authentication.
The Oracle SecurID Access Server may have multiple WebGates that communicate with it; however, all of these WebGates must be configured to communicate with the one Oracle SecurID Access Server only.
Important:
Failover is not supported for Oracle SecurID Access Servers. Only one Access Server can complete SecurID authentication.Each Access Server installation includes the SecurID authentication plug-in, authn_securid, located in the following directory. For example, on a Windows system:
\AccessServer_install_dir\access\oblix\lib\authn_securid
This plug-in is required in the SecurID authentication scheme. See "Creating a SecurID Authentication Scheme" for details about using the plug-in. See also "Oracle Access Manager Authentication Plug-In Parameters".
Each WebGate Web server used for SecurID authentication must support and pass header variables to CGI scripts, as follows:
Each WebGate that communicates with the Oracle SecurID Access Server must be configured to communicate with this Access Server only.
Only Oracle-provided WebGates are allowed for SecurID authentication. Do not use any other type of AccessGate.
Lotus Domino Web servers do not pass header variables to CGIs and cannot be used for SecurID authentication.
Older WebGates may coexist with 10g (10.1.4.0.1) Access Servers. However, encryption schemes differ:
Use RC4 as the encryption scheme if you have Oracle Access Manager Release 5.x WebGates co-existing in the same system with 10g (10.1.4.0.1) WebGates.
Use RC6 as the encryption scheme if you have Oracle Access Manager Release 6.x WebGates co-existing in the same system with 10g (10.1.4.0.1) WebGates.
Use the AES encryption scheme if you have only Oracle Access Manager Release 7.0 WebGates co-existing in the same system with 10g (10.1.4.0.1) WebGates.
The Perl plug-in or programming language, v5.005_03, is required on the each WebGate host that communicates with the Oracle SecurID Access Server that validates credentials with the ACE/Server.
A pointer to the location of Perl is required in the Oracle-provided SecurID CGI script on each WebGate involved in SecurID authentication (SecurID WebGate). See "Setting Up a SecurID WebGate" for details.
Included with each WebGate installation are the Oracle-provided SecurID authentication forms in the following directories:
WebGate_install_dir\access\oblix\lang\langTag\securid-forms
WebGate_install_dir\access\oblix\lang\langTag\securid-forms-adforest
The following forms are required to validate a user's SecurID credentials and to support New PIN and New Tokencode modes.
securid-accept-new-pin.html is not used today
securid-enter-new-pin.html
securid-new-pin.html
securid-new-pin-query.html
securid-next-tokencode.html
securid-std-login.html
With the exception of a domain name list for the Active Directory Forest that appears on certain forms, the forms in the two directories are the same. See "SecurID Authentication Scenarios" to see the forms.
Also included in the WebGate installation is the SecurID CGI script.
Each WebGate installation includes a SecurID CGI script in the following directory:
\WebGate_install_dir\access\oblix\lang\langTag\securid-cgi
During SecurID authentication operations, the WebGate uses the CGI script to present the appropriate SecurID form to the user based on information received from the Oracle SecurID Access Server and the ACE/Agent that communicates with the ACE/Server.
See "SecurID Authentication Sequence" for information on the standard SecurID login form.
See "New PIN Mode Support" and"New PIN Sequence" for more information about this mode of operation.
See "Next Tokencode Sequence" for more information about this mode of operation.
The following scenarios illustrate the three modes of operation:
When a user attempts to access a resource protected by the SecurID authentication scheme, the following process occurs. Figure 14-1 illustrates the sequence and is followed by a detailed description.
Process overview: When the user requests a resource
The WebGate intercepts the resource request and queries the Access Server to determine if and how the resource is protected, and if the user is authenticated.
The Access Server queries the directory for the authentication scheme, and receives authentication information from the directory.
The Access Server responds to the WebGate, which presents a form challenging the user for a two-part SecurID Passcode.
See "Active Directory Forest Considerations" to see the forms that include a domain for the Active Directory Forest.
The user submits credentials to the WebGate.
The WebGate presents the credentials to the Oracle SecurID Access Server.
The ACE/Agent on the Oracle SecurID Access Server performs the authentication dialog and sends an LDAP bind to the ACE/Server.
The ACE/Server database matches the SecurID passcode to the user ID and returns a success response to the ACE/Server, which matches the user's PIN.
The ACE/Server returns the response to its Agent, the Access Server. When the user's credentials are valid, SecurID authentication is successful.
The Oracle SecurID Access Server provides the response to the WebGate. A session is started for the user, so the same authentication method is not required for other Web servers in the domain. The WebGate then queries the Access Server for resource authorization:
Under certain conditions a New Tokencode mode may be initiated. See "Next Tokencode Sequence".
Under certain conditions a New Pin mode may be initiated. See "New PIN Sequence".
The Access Server queries the directory server used by Oracle Access Manager for authorization information which allows or denies access based upon the authorization rule.
When access is granted, the Access Server passes authorization to the WebGate, which presents the resource to the user.
The Master Access Administrator generates a shared secret key to encrypt cookies.
As discussed earlier, two modes may be triggered during the authentication sequence that will alter the user's experience. See "Active Directory Forest Considerations" for the forms specific to this environment.
When Next Tokencode mode is On, the user must supply the next tokencode on their SecurID token.
Process overview: When Next Tokencode is On
The WebGate CGI script presents a form to challenge the user for the next tokencode on the token following a successful login.
The user enters a username, waits 60 seconds, then enters the next tokencode on the SecurID token.
When the tokencode is correct, the Passcode the user originally entered is accepted and the user is authenticated.
See "Next Tokencode Mode Support" for details.
When the user is required to have a new PIN, the WebGate prompts the user with specific forms. The sequence is for generating a new PIN is provided in the following process overviews. See "New PIN Mode Support" for details.
Note:
When working in new PIN mode, if the user closes the New PIN Query page that appears upon accessing a resource and immediately tries to access the same resource from another browser instance, he or she can receive an error similar to the following:Oracle Access Manager Operation Error A plugin for the authentication scheme SecurID AuthT Scheme has aborted processing credentials (login=user123 password=(omitted) choice= newpin=newpin2= Resource=/securid-cgi/securid.pl RequesterIP=10.10.100.00 HostTarget=http://myhost.com:3333 Operation=POST rh=http://myhost.com:3333 ru=/test.html). Contact your website administrator to remedy this problem.
In most cases, if the user waits for more than 135 seconds before accessing the resource again, the new pin query page appears as expected.
Process overview: When New PIN mode is On
The WebGate SecurID CGI script presents the New PIN Query form to the user, as follows.
The user waits for the tokencode change, then completes the form and submits it to the WebGate.
The WebGate presents this to the Agent on the Oracle SecurID Access Server for submission to the ACE/Server.
The result is governed by the type of PIN the user requests. In either case, the New PIN process continues.
Process overview: When the user chooses to define a new PIN
WebGate presents the following form so the user can enter the PIN they want.
The user enters a username, then waits 60 seconds and enters the new tokencode and a new PIN to complete the form.
Important:
The user enters the next tokencode, not the passcode.The WebGate submits the information to the Agent on the Oracle SecurID Access Server, which is forwarded to the ACE/Server.
The ACE/Server registers the new PIN, which becomes part of the Pincode the user must supply during subsequent logins.
The requested resource is provided.
Process overview: When the user requests a system-generated PIN
The ACE/Server generates a new PIN and the WebGate presents the New PIN confirmation form to the user.
The user has 30 seconds to document the new PIN before the confirmation form is replaced with the following form, which prompts the user to accept the new PIN.
The requested resource is provided.
Before starting the integration you must complete all prerequisites. After that, you are ready to begin integrating SecurID authentication. The following is provided as an example. Any references to specific versions and/or platforms should be validated against the latest support information. See "Supported Versions and Platforms" for details.
Task overview: Integrating SecurID authentication
Set up your environment, as described in "Preparing Your Environment" .
Configure the Access Server, as described in "Setting up the Access Server as an ACE/Agent".
Configure the WebGate, as described in "Setting Up a SecurID WebGate".
Configure an authentication scheme, as described in "Creating a SecurID Authentication Scheme".
Identify resources to be protected, as described in "Protecting SecurID Resources" .
Test the policy domain, as described in "Testing the Policy Domain".
Add users, as described in "Adding ACE/Server Users to Oracle Access Manager".
Each of the following steps identifies a process that must be completed before you begin integrating SecurID authentication in Oracle Access Manager.
To prepare your environment for SecurID integration
Ensure that your RSA ACE/Server installation includes the latest patches and is running properly.
See "RSA ACE/Server Requirements" for details. See the installation instructions for RSA ACE/Server 5.1 for details and troubleshooting.
Confirm that RSA SecurID user authentication has been properly integrated with your RSA ACE/Server, and add users.
See the installation and configuration instructions for RSA SecurID for details and troubleshooting.
Ensure that Oracle Access Manager is set up and properly running, including the latest patches. Components include:
Identity Server and WebPass
Policy Manager and Access System Console
Access Server and WebGate(s)
See the Oracle Access Manager Installation Guide and Oracle Access Manager Identity and Common Administration Guide for general information.
Install the Perl plug-in or programming language, v5.005_03, on each WebGate that will communicate with the Oracle SecurID Access Server.
Note:
The following steps must be completed only when your Oracle Access Manager installation includes an Active Directory Forest. The Oracle-provided SecurID forms for the Active Directory Forest include place holders named Domain 1, Domain 2 and Domain 3. These must be changed to valid domain names that accurately reflect your Active Directory Forest installation.To prepare an Active Directory Forest
Set up and ensure that Oracle Access Manager works with your Active Directory Forest.
See the Oracle Access Manager Installation Guide for details about installing and deploying with Active Directory.
Edit the forms to display domain names for your Active Directory Forest. For example:
\WebGate_install_dir\access\oblix\lang\langTag\securid-forms-adforest
securid-std-login.html
securid-nexttokencode.html
securid-enter-new-pin.html
As discussed earlier, this task enables the Oracle SecurID Access Server to authenticate locally known users with the ACE/Server. The first time a user tries to authenticate through the registered Access Server, a node secret (password between the agent and the ACE/Server) is sent to the Agent in encrypted form and used to encrypt future communications.
Note:
Only one Access Server may communicate with the ACE/Server. However, all Access Servers require the ACE/Agent software.Task overview: Setting up the Access Server as an ACE/Agent
Register the host, as described in "Registering an ACE/Agent Host".
Set up the host, as described in "Setting up the ACE/Agent Host".
The following information focuses on successful SecurID integration with Oracle Access Manager. Providing complete details about ACE/Agents is outside the scope of this manual. See the administration guide for RSA ACE/Server 5.1 for details about ACE/Agents.
Before you install an ACE/Agent on the Oracle SecurID Access Server, you must add the server name, IP address, Agent and encryption types to the ACE/Server database. The Oracle SecurID Access Server must be designated as "open to all locally known users" and Agent Host auto registration should be enabled.
To register an Access Server as an ACE/Agent Host
Record the name and IP address of the one Access Server that will communicate with the ACE/Server for SecurID authentication.
Launch the ACE/Server database administration tool on the ACE/Server:
On Unix: sdadmin
On Windows: From the Start menu click Programs, then click ACE/Server Database Administration Host
Add your Agent Host name, IP address, Agent type, and encryption type.
For example:
Name: host_nameNetwork address: 192.168.1.140 Agent type: Unix Agent or Net OS Agent Encryption Type: DES
Ensure that the Access Server is designated as Open to All Locally Known Users.
Ensure that Sent Node Secret is disabled.
From the System menu, select Edit System Parameters.
Enable the Allow Agent Host Auto-Registration parameter, then confirm changing the system parameters.
Note:
Other parameters do not apply to the Access Server Agent.The ACE/Server's sdconf.rec file contains settings for all configurable ACE/Server system parameters and Agent Host settings. By default, this file resides in the following directory.
/ace/data/sdconf.rec
You will need a copy of this file on the Oracle SecurID Access Server that communicates with the ACE/Server.
You are ready to set up the Oracle SecurID Access Server as an ACE/Agent Host.
The steps in this procedure vary depending upon the platform you are using. See one of the following:
Path names in the following examples may not reflect the actual path names in your environment.
See "Oracle SecurID Access Server and ACE/Agent Requirements" for additional information.
On a Unix host, you must copy information from the ACE/Server to the Access Server. Then it is a good idea to verify the ACE/Agent installation on the Access Server, although this verification may be skipped.
To prepare a Unix-based Oracle SecurID Access Server
Locate and copy appropriate lines from the ACE/Server %systemroot%/drivers/etc/system to the Access Server /etc/system, for example:
Table 14-3 ACE/Server %systemroot%/drivers/etc/system to Access Server
| ACE/Server added to NIS | ACE/Server not added to NIS |
|---|---|
|
securid ... securidprop ... adlog ... sdserv ... sdadmind ... sdreport ... sdxauthd ... tacacs ... radius ... radacct ... |
set shmsys:shminfo_shmmni=100 set shmsys:shminfo_shmseg=16 set shmsys:shminfo_shmmax=16777216 set semsys:seminfo_semmni=64 set semsys:seminfo_semmsl=50 set semsys:seminfo_semmns=100 set semsys:seminfo_semmnu=100 |
Copy or FTP the sdconf.rec file from the ACE/Server to the Access Server. For example:
From ACE/Server: /ace/data/sdconf.rec
To Access Server:
/AccessServer_install_dir/access/oblix/config/securid/sdconf.rec
To verify the ACE/Agent installation on the Unix-based host (optional)
Locate and start the Agent installation program on the Access Server.
./sdsetup -agent [-p path]
Review configuration information and the Agent Host address field to confirm that you entered the correct hostname in the Access Server /etc/hosts file.
The first time the client is used for authentication, the node secret will be copied into a file named securid in the VAR_ACE directory on the client. Typically this is stored in the default path /OracleAccessManager/access/oblix/config/securid.
Ensure the VAR_ACE environment variable is set properly.
If it is not set properly, the node secret will not be copied the first time the client is used for authentication.
See the Unix installation instructions for the RSA ACE/Agent for additional information and troubleshooting tips.
On the Windows-based Oracle Access Manager SecurID Access Server registered as an ACE/Agent host, you must create a root certificate to define the encryption protocol between the Agent and the ACE/Server and copy the sdconf.rec file to the Access Server before you install the ACE/Agent software on the Access Server. Complete the following procedures:
Complete the steps in "To prepare a Windows-based Oracle SecurID Access Server" for the Oracle SecurID Access Server registered as an ACE/Agent host.
Complete the steps in "To install the ACE/Agent on each Windows-based Access Server" on every Access Server.
To prepare a Windows-based Oracle SecurID Access Server
Install the ACE/Agent Certificate Agent utility on the Access Server using the ACE/Server CD.
To start the ACE/Agent Certificate utility on the Access Server, click Start, then Programs, then ACE Agent , then ACE Agent Certificate Utility.
Create a root certificate for the machine and make a note of where this is stored.
New_Root
Certificate and keys
Host name: host_name
Organization: Name
Country: US
A certificate file is created for this host and, by default, is stored in the following directory path.
\Program Files\SDTI\ACE Agent Certificate\host_name.crt.
To install the ACE/Agent on each Windows-based Access Server
Copy or FTP the sdconf.rec file from the ACE/Server to the Access server.
For example:
From: D:\ace\data\sdconf.rec
To: C:\%systemroot%\system32\sdconf.rec
You are ready to install the ACE/Agent software on the Access Server. A Windows client requires ACE/Agent .dlls in the \WINNT\system32 directory. The minimum Agent installation is all you need to obtain the appropriate files: aceclnt.dll and sdmsg.dll.
Run agent.exe from the ACE/Server CD and select Common shared files and User documentation.
Specify the path to the root certificate you created earlier:
\Program Files\SDTI\ACE Agent Certificate\host_name.crt
Give the path to the sdconf.rec file that you copied to this machine:
\%systemroot%\system32\sdconf.rec
Repeat step 2 for the ACE/Server to the Access server through step 4 on each Access Server in your installation to include the aceclnt.dll and sdmsg.dll required for authn_securid plug-in initialization.
When you have the Access Server set up as an ACE/Agent you are ready to set up the SecurID WebGate(s).
Before you can use SecurID authentication, you must set up the SecurID WebGate Web server to successfully locate and use the Oracle-provided SecurID forms and the CGI script.
Task overview: Setting up a SecurID WebGate
Relocate the directories, as described in "Relocating Oracle SecurID Directories".
Set up the cgi script, as described in "Setting up the SecurID CGI Script".
Configure the cgi directory, as described in "Configuring the CGI Directory".
Note:
You must repeat the three procedures in this task on each WebGate used for SecurID authentication and ensure that each WebGate communicates with only the one Oracle SecurID Access Server.Successful SecurID authentication requires that the three Oracle-provided securid directories installed with the WebGate are located in a directory that is configured as the Web server's document directory. This can be:
The primary document root
or
A virtual document root
Unless the WebGate was installed under the Web server's document root, you must relocate a copy of the Oracle-provided securid directories.
To relocate the Oracle-provided SecurID directories
Locate the three securid directories on your WebGate host. For example, on a Windows system:
\WebGate_install_dir\access\oblix\lang\langTag\securid-cgi
\WebGate_install_dir\access\oblix\lang\langTag\securid-forms
\WebGate_install_dir\access\oblix\lang\langTag\securid-forms-adforest
Note:
If the three SecurID directories are in the Web server's primary document or a virtual document root directory, skip to "Setting up the SecurID CGI Script". Otherwise, complete step 2.Copy the three securid subdirectories under a Web server document directory.
For example:
\iPlanet\WS6sp4\docs\OracleAccessManager\securid-cgi \iPlanet\WS6sp4\docs\OracleAccessManager\securid-forms \iPlanet\WS6sp4\docs\OracleAccessManager\securid-forms-adforest
Later, when you create a SecurID authentication scheme, you may need to adjust your scheme challenge and authn_securid plug-in parameters accordingly. See "Creating a SecurID Authentication Scheme".
To operate properly, the Oracle-provided SecurID CGI script must point to the correct location of Perl v5.005_03 on the WebGate.
As shown in the following paragraphs, the three SecurID directories were copied from their original installation directory to the Web server's document root using the previous steps.
Open the Oracle-provided securid.pl script.
For example:
\iPlanet\WS6sp4\docs\OracleAccessManager\securid-cgi\securid.pl
Ensure that the first line points to the correct location of Perl on this WebGate.
For example:
#!/usr/bin/perl -w
Next, you will set up the CGI directory on the WebGate Web server.
The Oracle-provided SecurID CGI directory must be configured as a CGI directory on the Web server. This process will vary depending on your Web server platform:
On IIS Web servers: You need only ensure that the Oracle-provided script is an executable.
On iPlanet Enterprise Web servers: You need only configure the CGI directory as a Web server CGI directory.
On Unix: Specify a Programs/CGI directory
On Windows: Specify a Shell/CGI Directory
On Apache Web servers: You must modify the httpd.conf file as follows:
Add the Oracle-provided CGI script to the AddHandler section, or uncomment it.
Add ExecCGI to a Directory container that applies to the directory where the Oracle-provided script is located.
Add PassEnv lines outside all Directory and VirtualHost containers.
See the documentation that accompanies your specific Web server for more information.
To configure the CGI script on IIS Web servers
Locate the securid.pl file.
Make the securid.pl file an executable.
See the Microsoft IIS Web Server Administration documentation for details about converting the script to an executable.
To configure a CGI directory on the iPlanet Enterprise Server
Log in as the Web Server Administrator, then select your server name and click Manage.
Select the Virtual Server Class tab, click the Manage button, and then click the Programs tab.
Select the CGI directory for your platform. For example:
Unix: Programs/CGI Directory
Windows: ShellCGI Directory
Add the URL prefix and the full path to the CGI directory, as shown in the following Windows example:
URL prefix: OracleAccessManager\securid-cgi
CGI directory: C:\iPlanet\WS6sp4\docs\OracleAccessManager\securid-cgi
See the documentation for the iPlanet Web Server Administration Server for more information.
To configure Apache Web servers for the SecurID CGI script
Locate the httpd.conf file and add the following information to the AddHandler section, or uncomment the line if it is already there.
AddHandler cgi-script .pl
Note:
Be sure to include the space in AddHandler cgi-script .pl; otherwise, the Web server won't start.Find a <Directory> container that applies to the directory where you have stored the securid.pl file, and add "ExecCGI" to the end of the line that reads
"Options Indexes FollowSymLinks MultiViews," as follows:
Options Indexes FollowSymLinks MultiViews ExecCGI
Add the following lines outside all <Directory> and <VirtualHost> containers.
PassEnv HTTP_COOKIE PassEnv HTTP_REDIRECTURL PassEnv HTTP_FULLFORMDIR PassEnv HTTP_HTTPTYPE PassEnv HTTP_NEWPINRETURN
See the Apache Web Server documentation for additional details.
Next you will create a SecurID authentication scheme that uses the Oracle-provided SecurID plug-in.
This section provides the following topics.
Even if you are familiar with Oracle Access Manager authentication plug-ins, you may want to focus on specific SecurID requirements presented earlier.
Some information offered in the following examples should be replaced with the appropriate information for your environment.
The Access System protects resources according to policy domains. Each policy domain identifies the resources to be protected and must include one and only one authentication rule. That rule, which is considered the default authentication rule, must contain an authentication scheme which specifies the challenge method used to obtain credentials from the user. Each authentication scheme can include one or more plug-ins to perform additional processing. For Smart Card authentication, you must use the Client Certificate authentication scheme.
A policy domain can include policies to protect resources within the domain in a different or more specific way. Each of these policies can have its own authentication rule, but one is not required. If an authentication rule is not configured for a policy, the default authentication rule for the policy domain applies.
Until the Master Access Administrator delegates administration rights to a policy domain, he or she is the only person who can access that policy domain.
The following form is used to define the authentication scheme. This is available in the Access System Console, Access System Configuration Authentication Management function.
An authentication scheme name is required. The description is optional. The security level definition is the same for all authentication schemes. For more information about authentication schemes, see the Oracle Access Manager Access System Administration Guide.
The following discussions provide additional details for SecurID:
SecurID Challenge Method
Each authentication scheme requires a challenge method to obtain user credentials for authentication. Only one challenge method is allowed per authentication scheme.
SecurID requires the form-based challenge method, which means that the user must complete an HTML form during the authentication process. Form-based authentication schemes can pass authorization actions in header variables but cannot pass authentication actions in header variables.
The Basic challenge method does not support SecurID Pincodes, Next Tokencode Mode, nor New PIN Mode.
See the Oracle Access Manager Access System Administration Guide for more information about authentication scheme challenge methods.
Note:
Do not protect a challenge form or any of its components, such as .gifs and links.SecurID requires four challenge parameters to identify what will occur when a user logs in. The four challenge parameters are action, passthrough, creds, and form.
action: You can use the action parameter to present a form to authenticate the user after receiving an initial request for a resource. For SecurID authentication, the form action is initiated by the Oracle-provided CGI script.
The default location of the SecurID CGI script is as follows:
\WebGate_install_dir\access\oblix\lang\langTag\securid-cgi\securid.pl
Relocated to: \iPlanet\WS6sp4\docs\OracleAccessManager\securid-cgi\securid.pl
When the script is installed on a single Web server instance, the relative path is sufficient.
When the script is on a different Web server instance, the full URL path is required.
passthrough: Passthrough is set to No by default. For SecurID authentication, set passthrough to Yes to pass the login credentials to a post-processing program.
creds: The creds parameter identifies all fields used for login in the HTML forms, in a space-separated list. The parameters needed for SecurID authentication must correspond to fields in the SecurID authentication HTML forms and SecurID plug-in parameters. For example:
login username password passcode choice
choice_label_such_as_system-generated newpin
PIN_entered_by_the_user newpin2 PIN_re-entered_by_the_user
The creds challenge parameter for the user ID should match the user ID specified in the credential_mapping plug-in that is required with SecurID authentication. For example:
Challenge Parameter: creds:login
credential_mapping plug-in parameter: obMappingFilter="(&(...userid=%login%))"
form: The form parameter indicates where the standard login HTML form is located relative to the Web server's document directory.
For example, when the full path is: \iPlanet\WS6sp4\docs\OracleAccessManager\securid\securid-forms\securid-std-login.html
The form parameter is: \securid-forms\securid-std-login.html
SecurID Authentication Scheme Plug-Ins
Two plug-ins are required in the SecurID authentication scheme, authn_securid and credential_mapping. Each plug-in defines how information will be looked up in the directory server. Again, the following examples illustrate concepts and may not portray your environment.
The authn_securid plug-in authenticates the user's SecurID credentials against their credentials on the ACE/Server. The two mandatory parameters include fullformdir and machine.
fullformdir: This parameter identifies the full and complete path from the Web server root to the authentication form directory. For example:
fullformdir=C:\iPlanet\WS6sp4\docs\OracleAccessManager\securid-forms fullformdir=C:\Webserver_root\OracleAccessManager\securid-forms-adforest
machine: This parameter identifies the fully qualified machine name, including the domain name and port of the WebGate Web server instance that will communicate with the Oracle SecurID Access Server.
machine=host_name.domain.com:port
The credential_mapping plug-in maps the user-provided information to a valid Distinguished Name (DN) in the directory used by Oracle Access Manager. Ensure that the user ID you specify matches the creds parameter you specified in the challenge parameter.
obMappingBase="o=company,c=us" obMappingFilter="(&(objectclass=...orgperson)(...userid=%login%)"
A number of parameters are available with each plug-in. See "Oracle Access Manager Authentication Plug-In Parameters" for more information. With these considerations in mind, you are ready to define the SecurID authentication scheme.
Only a Master Access Administrator may create authentication schemes. The following steps walk you through the process you must complete to define a SecurID authentication scheme. Differences for an Active Directory Forest are noted where appropriate. See also "Active Directory Forest Considerations".
In the following example, the action URL points to the new location of the securid-cgi directory as discussed in "Relocating Oracle SecurID Directories". Path names may differ in your environment.
To define the SecurID authentication scheme
From the Access System Console, click Access System Configuration, from Access System Configuration menu click Authentication Management
Click the Add button at the bottom of the panel.
Enter a name, optional description, and security level for your SecurID authentication scheme.
For example:
Name: SecurID Authentication
Description: This scheme requires a user to enter a SecurID username (login) and passcode. This scheme also handles Next Tokencode mode and New PIN mode.
Level: An integer between 1 and 5 defines the security level.
Select Form as the challenge method and enter challenge parameters for this authentication scheme.
For example:
Challenge Method: Form
Challenge Parameters:
action:\OracleAccessManager\securid-cgi\securid.pl
passthrough:yes
creds:login password choice newpin newpin2
form excluding Active Directory Forests: form:\iPlanet\WS6sp4\docs\OracleAccessManager\securid-forms\securid-std-login.html
form for Active Directory Forests only: form:\Webserver_root\OracleAccessManager\securid-forms-adforest\securid-std-login.html
Next, you will create a customized challenge scheme using the authn_securid and credential_mapping plug-ins.
The authn_securid plug-in should be the first. Be sure that the machine parameter includes the fully qualified domain name and port or the host identifier or one of its aliases as specified in the Access System Console. See "SecurID Plug-In Parameters" and "Credential Mapping Plug-In Parameters" for details.
Select No beside SSL Required.
If you have more than one WebGate/Access Server pair, redirect to a WebGate that communicates with the dedicated Oracle SecurID Access Server. Use the fully qualified machine name. Syntax:
http://host_name.domain.com:port/
Note:
When you have only one WebGate/Access Server pair, leave the Challenge Redirect field blank and skip to step 8.Enter a challenge redirect, as needed for your environment.
Save.
Click the Plug-Ins tab, the Modify button, then select Custom Plugins from the drop down list and specify parameters.
For example:
Plug-in Name: authn_securid
Plug-in Name Parameters (excluding Active Directory):
fullformdir="c:\iPlanet\WS6sp4\docs\OracleAccessManager\securid-forms", machine="host_name.domain.com:port"
Plug-in Name Parameters for Active Directory:
fullfordir="c:\Webserver_root\OracleAccessManager\securid-forms-adforest",machine="host_name.domain.com:port"
Select the credential_mapping plug-in from the drop down list and specify parameters.
For example:
Plug-in Name: credential_mapping
Plug-in Name Parameters (excluding Active Directory): obMappingBase="o=company,c=us", obMappingFilter="(&(objectclass=...orgperson) (...userid=%login%))"
Plug-in Name Parameters for Active Directory: obMappingBase="%domain%", obMappingFilter="(?(objectclass=user) (samaccountname=%login%))"
Check Update Cache to have this take effect immediately, then click Save.
Restart the Access Server to load the plug-ins.
You have finished creating a SecurID authentication scheme that will appear in the Authentication Scheme list when you assign rules to a policy domain. See the Oracle Access Manager Access System Administration Guide.
Important:
Before you use this scheme, the form's action URL must be protected by a Oracle Access Manager policy domain and the action challenge parameter of the form scheme must match the form action URL.Before you can use the SecurID authentication scheme in a policy domain, you must protect the Oracle-provided SecurID CGI script specified in the action URL of your SecurID authentication scheme. Once protected, you may use the scheme in new policy domains to protect other resources with SecurID authentication.
Note:
As shown in the following paragraphs, when protecting the SecurID CGI script you may use any authentication scheme except the SecurID authentication scheme. Also, do not protect the forms or any elements in the forms (.gifs, for example).Task overview: Protecting Securid Resources
Create a policy domain, as described in "Creating a Policy Domain".
Add resources to the policy domain, as described in "Adding a Resource to Your Policy Domain".
Define rules for the domain, as described in "Defining Rules for this Domain".
The key to creating an effective policy domain is to group the content that you want to manage in the same way. Each policy domain is defined using the Policy Manager and each policy domain includes a definition of:
Resources to protect
Schemes, rules, and optional policies (exceptions) for protection
Administrative rights, optional
For example, you need one policy domain to protect the SecurID authentication script and action URL for the Scheme. This cannot be protected by the SecurID authentication scheme. You will want another policy domain to protect resources using the SecurID authentication scheme.
The following procedure shows how to create a policy domain to protect the SecurID CGI script. Following each sequence is a brief example of a second policy domain that will use the SecurID authentication scheme to protect other resources. The information provided is a sample to illustrate concepts.
The following procedure requires specific policy domain management rights. See the Oracle Access Manager Access System Administration Guide for details.
To create a policy domain to protect the SecurID script
Launch the Access System Console:
http://host_name.domain.com:port/access
Select the Policy Manager.
The My Policy Domains page appears with functions on the left and current policy domains on the right.
Click Create Policy Domain on the left.
The General tab is highlighted and the Name field is active.
Enter a name and an optional description for the new policy, then save it.
For example:
Name: SecurID-script
Description: Oracle-provided
Note:
The policy domain cannot be enabled until you add a resource type.Only a Master Access or Master Oracle Access Manager Administrator may add resources to a policy domain. When Oracle Access Manager is initially installed, no resources are defined. Your environment may include resources.
A resource may be either static or dynamic content.
Static content includes HTML pages, .gifs, .pdfs
Dynamic content includes scripts, applications, EJBs
For this integration, you will add the securid-cgi as a resource for the policy domain to protect the Oracle-provided SecurID script.
The administrator who created the first policy domain set the existing root URL used as a base for the policy domain. You may append a different region to the same prefix to define a new URL prefix that is available to other policy domains.
Again, sample specifications to protect a resource with the SecurID authentication scheme are included with the following procedures. However, you cannot use the SecurID authentication scheme until you protect the SecurID script.
To add a resource to your policy domain
From the Policy Manager policy domain page, click the Resources tab then click the Add button and add a resource.
For example:
Resource Type: http URL Prefix (and region): / OracleAccessManager/securid-cgi Description: Optional
Ensure that Update Cache is enabled, then save.
Click the Save button and review the information you supplied.
All Administrators may create an authentication expression for a policy domain or policy. An existing authentication scheme must be specified as the building block.
As discussed earlier, you must protect the SecurID authentication script specified in the action URL of the authentication scheme before you can use the scheme.
When completing the following steps, skip to step 2 if the Default Rules tab is available.
From the landing page for the Access System, select the Policy Manager application, click My Policy Domains, and from My Policy Domains select Securid-script.
Click the Default Rules tab, then click the Add button.
Enter the details and confirm that you are using the Oracle Access and Identity authentication scheme.
For example:
Name: Securid Authentication
Description: Optional
Authentication Scheme: Oracle Access and Identity
Ensure that Update Cache is enabled, click the Save button, then review the information summary.
When protecting the SecurID CGI script, you do not want to deny access to anyone. When protecting the SecurID CGI script, allowing everyone enables the Access Server to check each user's credentials with the ACE/Server. By default, nobody is authorized. Allowing access should take precedence.
Click the Authorization Rules tab, choose Oracle Authorization Scheme from the drop down list, then save.
For example:
Authorization Scheme: Oracle Authorization Scheme
Enter a name, an optional description, enable this scheme, ensure that Allow takes precedence, then save.
For example:
Name: SecurID allow_all
Description: Optional
Enabled: Yes
Allow takes Precedence: Yes
In every case, including SecurID CGI script protection, you must specify the Role of those being granted access to this policy domain. For your environment, you may want to grant access only to specific users or groups.
Click the Allow Access tab, click the Add button, fill in the form, and save.
For example, to grant access to anyone from the root directory down:
Role: Anyone
Rule: ldap:///Update Cache
Though not required to protect the SecurID CGI script, you may apply one or more policies to fine-tune access control for the protected resources and apply auditing rules to record access requests and resource use. For these activities, you must have authorization granted by an Access Administrator.
Click the General tab and enable the policy domain.
The policy domain is active and the resource is protected. In this case, the SecurID CGI script is protected by the Oracle Access and Identity authentication scheme and ready to use in policy domains that protect your resources.
Repeat "Protecting SecurID Resources" to protect your own resources using the SecurID authentication scheme.
See the Oracle Access Manager Access System Administration Guide for details about policy domains.
The best way to help you identify and resolve any problems that might arise is to test the policy domain and check various log files to ensure that everything is working properly. See the appropriate manuals for your systems for details.
Enable logging on your Web servers to help track any anomalies during operation.
Enable logging your Oracle SecurID Access Server.
Enable logging on your SecurID WebGate or WebGates.
Enable logging on your RSA ACE/Server to report activity in real time or to create an activity log, as usual.
Test your policy domains and Web single sign-on, as usual, to ensure that all are working as expected.
You must add ACE/Server users to the directory used by Oracle Access Manager to enable access to the protected resource after the user is authenticated.
One way to do this is to use the Identity System User Manager application to create a workflow definition. Creating a workflow for this purpose is no different than creating a workflow to add other users, as long as you include the following attributes as a minimum.
Name
Last Name
Login
Password
See the Oracle Access Manager Identity and Common Administration Guide for details about creating a workflow definition.
SecurID authentication requires the SecurID plug-in and the Credential Mapping plug-in. Each plug-in provides a number of parameters to direct how information is looked up in the directory server.
This section discusses the following topics:
The parameters in Table 14-4 apply to the authn_securid plug-in when defining the SecurID authentication scheme in Oracle. You may customize the parameter name according to the rules specified in the comments in Table 14-4 These parameters are case sensitive.
Table 14-4 authn_securid Plug-In Parameters
| Parameter Name | Default Value | Status | Comments |
|---|---|---|---|
|
httpType |
http:// |
Optional |
If the webgate doing the SecurID authentication is in SSL, the value should be changed to https:// by passing additional parameter httptype="https://" |
|
fullformdir |
<none> |
Mandatory |
This is the full path to the SecurID forms used for authentication, from the Web root to the directory that contains the forms. The value requires a trailing slash. For example: fullformdir="C:/iPlanet/WS6sp4/docs/ OracleAccessManager/securid-forms/" or, for Active Directory fullformdir="C:\Webserver_root/OracleAccessManager/securid-forms-adforest/" By default, the forms directories are installed as follows and should be moved to the Web server's document directory: \OracleAccessManager\webcomponent\access\oblix lang\langTag\securidxxx |
|
machine |
<none> |
Mandatory |
This is the fully qualified domain name and port number of the Web server instance that will communicate with the Oracle SecurID Access Server. For example: machine="machine.domain.com:port"
|
|
formdir |
access/oblix/securid-forms |
Optional |
This is the relative path to the SecurID forms and requires a trailing slash. Note: If you customize this value, you must also change it in the Challenge Parameter, form, and SecurID plug-in parameter, fullformdir. In other words, if you place the SecurID forms anywhere other than: webserver_docroot/access/oblix/securid-forms you must pass the formdir parameter to the authn_securid plug-in with the value appropriately changed. The new value should be the location of the forms relative to the doc_root. Also, the value should not include a trailing slash. Also, if the securid cgi script is not accessible at webserver_docroot/access/oblix/securid-cgi/securid.pl, you must edit the various SecurID html forms to point to the correct location. You need to change the following text in each form to point to the correct location of the script. action="/access/oblix/securid-cgi/securid.pl" |
|
username |
login |
Optional |
If you are using the sample forms, set this value to: login. If you customize this value, you must also change it in the Challenge Parameter, creds and also in the credential_mapping obMappingFilter. |
|
passcode |
password |
Optional |
If you are using the sample forms, set this value to: password. If you customize this value, you must also change it in the Challenge Parameter, creds. |
|
choiceLabel |
choice |
Optional |
This is the name of the field in the HTML form corresponding to the user's choice of how a PIN is generated. If you customize this value, you must also change it in the Challenge Parameter, creds. |
|
newpinLabel |
newpin |
Optional |
This is the name of the field in the HTML form corresponding to the new PIN entered by the user. If you customize this value, you must also change it in the Challenge Parameter, creds. |
|
newpinLabel2 |
newpin2 |
Optional |
This is the name of the field in the HTML form corresponding to the new PIN that is re-entered by the user. If you customize this value, you must also change it in the Challenge Parameter, creds. |
This plug-in maps the user ID to a valid distinguished name (DN) in the directory used by Oracle Access Manager. You can configure the attribute to which the user ID is mapped to find the DN. The most common attribute that is mapped to is uid. However, it is possible to map the user ID to a profile attribute other than uid by changing the obMappingFilter parameter. See Table 14-5. These parameters are case-sensitive.
Table 14-5 Credential_mapping Plug-In Parameters
| Parameter | Usage Rule | Description |
|---|---|---|
|
obMappingBase |
Defines the Base DN in the LDAP search. If omitted or empty, the directory base is used. |
|
|
obMappingFilter |
Mandatory |
Defines the Filter in the LDAP search. This parameter enables use of the obMappingFilter term to filter for categories of end users. |
|
obdomain |
Needed with Active Directory Forests |
Authenticates a user against an Active Directory Forest when the challenge method is Basic. |
|
EnableCredentialCache |
Turns off the credential mapping cache in the credential_mapping plug-in. You may want to turn off the cache if the same user ID may be mapped to different DNs. See the Oracle Access Manager Developer Guide for more information. |
Two subordinate parameters may be used with the obMappingFilter. These parameters can only be used with the obMappingFilter parameter. See Table 14-6.
Table 14-6 obMappingFilter Subordinate Parameters
| Parameter | Description |
|---|---|
|
obuseraccountcontrol |
When this parameter is activated, or if there is no value, two categories of end users are filtered out:
|
|
obEnableCredentialCache |
Turns off the credential mapping cache in the plug-in to deactivate the user the next time they authenticate. |
The following information can be found throughout discussions in this chapter. They are repeated here for quick reference.
This section discusses the following topics:
Before integrating SecurID authentication with an Active Directory Forest, you must complete the tasks in the following task overview.
Task overview: To prepare your environment
Complete all tasks in "Preparing Your Environment" to set up the RSA ACE/Server, SecurID tokens and users, and Identity and Access Systems.
Set up and ensure that Oracle Access Manager works with an Active Directory Forest.
See the Oracle Access Manager Installation Guide and Oracle Access Manager Identity and Common Administration Guide for details about installing and deploying with an Active Directory Forest.
Edit the following forms to replace the place holder domain names with actual domain names for your Active Directory Forest installation. For example, \WebGate_install_dir\access\oblix\lang\langTag\securid-forms-adforest.
securid-std-login.html
securid-nexttokencode.html
securid-enter-new-pin.html
Any differences for an Active Directory Forest are included for quick reference and are embedded in discussions elsewhere in this chapter.
In the following example, the action URL points to the securid-cgi directory as shown in "Relocating Oracle SecurID Directories". Path names may differ in your environment. Bold indicates the items that are different for an Active Directory Forest.
Note:
This section assumes you have completed the following tasks:To integrate SecurID authentication
Follow the instructions in "Creating a SecurID Authentication Scheme" with the following changes for the Active Directory Forest.
Changes for Active Directory Forest Challenge parameters:
form: \Webserver_root\OracleAccessManager\securid-forms-adforest\securid-std-login.html
Changes for Active Directory Forest plug-ins and parameters:
Plug-in: authn_securid
Parameters: fullformdir="c:\Webserver_root\OracleAccessManager\securid-forms-adforest",machine="host_name.domain.com:port"
Plug-in: credential_mapping
Parameters: obMappingBase="%domain%", obMappingFilter="(?(objectclass=user) (samaccountname=%login%))"
Select Update Cache, then Save to complete your SecurID authentication scheme.
Restart the Access Server to load the plug-in.
Complete the tasks described in the following sections:
As you can see on the following Oracle-provided forms, the only difference between standard forms for SecurID authentication and the forms provided for SecurID authentication with an Active Directory Forest is the inclusion of the Domain name on the Login form, Next Tokencode form, and New PIN Entry form.
The form in Figure 14-2 includes the Domain list. See "SecurID Authentication Scenarios" for the standard forms.
The form in Figure 14-3, "Next Tokencode Form for Active Directory Forest" includes the Domain list. See "Next Tokencode Sequence" for the standard form and a description of the sequence of events that occurs in this mode.
See "New PIN Sequence" for the standard forms for the New PIN sequences and a description of the events that occur with this sequence. As shown in Figure 14-4, "New PIN Query", the New PIN Query form is slightly different.
User-Defined PIN Form
If the PIN was defined by the user, they are challenged by the form and asked to enter their:
Username
Tokencode (shown in the form as Passcode)
New PIN
Active Directory Domain
The form in Figure 14-5 includes a Domain list.
Following is a brief list of some of the things to check if SecurID authentication is not working as expected.
If an "unable to resolve" or "Error:gethostbyname failed" message appear in the CLIENT ADDRESS field when configuration data is displayed, you probably entered the client hostname incorrectly in the /etc/hosts file. In this case, you must edit the host entry to solve the problem.
If the authn_securid plug-in fails to initialize in an environment with multiple Windows-based Access Servers, verify the status of each Access Server as discussed in the following procedure.
To verify the status of each Windows-based Access Server
Confirm that each Windows-based Access Server in your environment has the RSA ACE/Agent software installed.
See "Setting up the Access Server as an ACE/Agent" for details.
Confirm that only one Access Server is registered with the RSA ACE/Server as the Oracle SecurID Access Server.
See "Registering an ACE/Agent Host" and "Setting up the ACE/Agent Host" for details.
The RSA ACE/Server sdconf.rec file is required on the Oracle SecurID Access Server before you can install the RSA ACE/Agent on the Access Server.
This RSA ACE/Server file contains all configurable items for the RSA ACE/Server, including Agent Host specifications.
You must copy this file to the Access Server that will validate user credentials with the ACE/Server before you add the ACE/Agent to the Access server. See "Setting up the Access Server as an ACE/Agent" for details.
Ensure that the securid-cgi directory is set up properly on the WebGate.
Task overview: Testing the securid-cgi directory
Unprotect a different CGI in the same directory.
Access the unprotected CGI to be sure you set up the CGI directory properly.
See "Setting Up a SecurID WebGate" for details.
When setting up your Oracle SecurID Access Server as an ACE/Agent host, ensure the VAR_ACE environment variable is properly set on your Unix system. See "Setting up the Access Server as an ACE/Agent" for more information.
Ensure that form-based authentication is set up properly, as described in the Oracle Access Manager Access System Administration Guide.
If this the first time the authn_securid plug-in has been configured, you must restart the Access Server to load the plug-in.
If an authentication plug-in returns an error, it is logged in the Access Server log. You configure this in the Access System Console.
To set up the Access Server log
From the Access System Console, click Access System Configuration, then click Access Server Configuration
Select the server name from the List of All Access Servers, then click Modify.
Set Debug On and enter a file name.
Restart the Access Server.
These can provide many clues as to what is going wrong. Be sure the enable logging on your Web server.
See the documentation for your Web server for details.
If communication has been established between the Access Server and ACE/Server, the sdadmin tool provides access to logs under the Report menu. Both Activity and Exception reports may give you helpful information.
To verify the ACE/Server log configuration
Confirm that you have added the user and assigned a token using the ACE/Server Administrator tool, sdadmin.
Verify that you have copied the sdconf.rec file to the Access Server before installing the ACE/Agent.
See "Setting up the Access Server as an ACE/Agent" for details.
Locate the following file in the Web server's document root directory to ensure that the shared secret was downloaded on the first connection between the Oracle SecurID Access Server and the ACE/Server. For example:
\iPlanet\WS6sp4\doc\OracleAccessManager\securid
Permissions can sometimes cause problems.
Confirm that the following permissions are appropriate:
On the SecurID CGI script, securid.pl
On the SecurID HTML forms
On all files
On the page you are trying to reach
Note:
Do protect the securid.pl script on the WebGate or WebGates. Do not protect the SecurID forms or their directories.If you have modified the HTML field names in the HTML forms, make sure you have modified the SecurID plug-in parameters to match.
User logins can fail if you provide an at-sign ("@") in the login attribute value. If you have an at-sign in the login attribute value, you must remove the -w switch from the first line of the securid.pl script.
This is a known issue with SecurID.
