Policy Server Guides › Policy Server Configuration Guide › Authentication Schemes › SecurID Authentication Schemes

SecurID Authentication Schemes

The RSA Ace/SecureID authentication schemes authenticate users logging in with ACE credentials, which include the user names, PINs, and TOKENCODEs. ACE user names and passwords reside in an ACE/Server user store, and an ACE/Server administrator can change these credentials. SecureID tokens generate single-use TOKENCODEs.

The following SecurID authentication schemes are available:

SecurID Authentication

This scheme authenticates users who are logging in with RSA SecureID hardware tokens. The scheme accepts a user name and password. The password is the user’s token PIN followed by the dynamic code.

Note: Use the LDAP directory attribute 'uid' to map to the userid of the user on the Ace Server, otherwise the SecurId Template authentication scheme fails to authenticate the user. Use the SecurID HTML Forms Template when mapping LDAP directory attributes other than uid to the userid on the Ace Server.

SecurID Authentication with HTML Forms Support

This scheme includes HTML forms support. The HTML forms lets users identify themselves and reactivate their accounts after they have been disabled because they entered their PIN or token information incorrectly.

The RSA ACE/SecurID scheme authenticates users who are not allowed to change their ACE PIN or users who are not in the NextTokenCode mode. However, users who change their PIN and users who are in the NextTokenCode mode are authenticated through the RSA ACE/SecurID scheme with HTML form. Both schemes are based on ACE/Server - Ace/Agent model and require RSA/SecurID (tokens) and RSA/ACE (server software) products.

The RSA ACE/Server works with RSA SecurID tokens to authenticate user identities through valid RSA Ace/Agents. Further, RSA supports Web Agents and custom Agents. The SecurID authentication schemes act as custom ACE/Agents and use ACE/SDK and libraries.

The ACE/Server, however, has its own policy in handling user credentials and stores this information in the ACE user store. The policy includes several requirements and limitations for each user, which the ACE administrator can change at any time. The administrator configures users to authenticate by either PIN or TOKENCODE. If users are configured to authenticate by PIN, the system does not require a TOKENCODE. If users are configured to authenticate with a TOKENCODE, the TOKENCODE and PIN are required. In addition, users can be required to set a new PIN while trying to authenticate. Under this "new PIN mode", the old and new PINs are required.

To authenticate users, the SecureID authentication schemes require mapping between the ACE server and the users in the user store. This mapping is represented as an authentication scheme object attribute in the policy store.

The enhancement to the RSA ACE/SecurID Scheme with HTML form affects the "new PIN mode".

The following figure shows how the RSA ACE/Server interacts with the Policy Server:

The flow is as follows:

1. A user requests a resource such as a web page.
2. The Web Agent determines if the resource is protected.
3. The Policy Server indicates that the requested resource is protected by the RSA ACE/SecurID authentication scheme with HTML form.
4. The Web Agent prompts the user for credentials.
5. The user enters credentials and the Agent sends them to the Policy Server.
6. The Policy Server performs user disambiguation and maps the user name to RSA/ACE user name. The Policy Server does not apply password policies.
7. The Policy Server forwards the authentication request to the ACE/Server by making a sequence of ACE API calls. The Server also sends the user’s credentials to the ACE/Server.
8. The ACE/Server indicates that the user is required to change the PIN and then returns control back to the Policy Server.
9. The Policy Server returns control to the Web Agent and then the Agent redirects the user to a CGI or JSP.
10. The CGI or JSP generates the applicable HTML form. The form is presented to the user, and then prompts for a user name, old PIN, new PIN, and new PIN confirmation.
11. The Web Agent sends a new set of credentials to the Policy Server.
12. The Policy Server makes a new sequence of API calls to the ACE/Server.
13. If new the PIN is accepted, then the ACE API call returns success. From here, the user is asked to log in with the new PIN and the authentication process is complete.
14. If new PIN is rejected, Step 10 to Step 12 are repeated.

The PIN can be rejected under the following conditions:

• The PIN is too long
• The PIN is too short
• The PIN contains alphabetic characters

In the previous figure, authentication includes presenting back-end PIN policy-related messages on the HTML form. The SecurID Authentication scheme does the PIN policy validation before sending a new PIN to the ACE/Server. The ACE SDK has a set of functions that can retrieve the following PIN attributes:

• Maximum length
• Minimum length
• Alphabetic and numeric or only numeric characters

Based on this information, the PIN is validated and the appropriate error messages are constructed and presented to the user. The validation is done in the following order:

• The PIN is not too long
• The PIN is not too short
• The PIN does not have invalid characters

The only relevant portion of the policy is made available to users in these new error messages. The following shows an example of how these new messages can appear:

If a sample user, Joe, has a PIN of 5 to 8 digits long but enters a new PIN "poem", then the following error message displays:

Your new PIN is too short. PIN must contain at least 5 character(s).

If the next specified PIN is "novel", the message is:

Your new PIN may not have alphabetic characters.

If the next specified PIN is "123412341234," the message is:

Your new PIN is too long. PIN must contain 8 or fewer character(s).

Despite the successful PIN validation by the SecureID authentication scheme, the ACE/Server can reject a new PIN. In this case, the user is asked for a new set of credentials, but no reason is given. Further, in the enhanced SecurID authentication scheme, the user is automatically granted access to the target web page after a successful PIN change.

How to Configure a SecurID Authentication Scheme

To configure a SecurID authentication scheme, do the following procedures:

1. Review the SecurID scheme prerequisites.
2. Configure a SecurID authentication scheme.

SecurID Scheme Prerequisites

Be sure that the following prerequisite is met before configuring a SecureID authentication scheme:

• If the following conditions are true, configure the ACE paths to point to the location of the SecurID file:
  • The ACE environment is using ACE Client 7.0 or later.
  • The ACE environment is not using a Node Secret.
  • The ACE environment is protecting another application, which the Policy Server does not protect.
  • The ACE environment is protecting another third-party product.

  Configuring the ACE paths prevents the authentication request that the Policy Server sends to the ACE Server from failing.

Note: The SM_ACE_FAILOVER_ATTEMPTS environment variable has been removed. This variable was used to set the failover attempts to the ACE server.

Configure a SecurID Authentication Scheme

You can use a SecurID authentication scheme to authenticate users logging in with ACE credentials.

Note: The following procedure assumes that you are creating an object. You can also copy the properties of an existing object to create an object. For more information, see Duplicate Policy Server Objects.

Follow these steps:

1. Click Infrastructure, Authentication.
2. Click Authentication Schemes.
3. Click Create Authentication Scheme.

   Verify that the Create a new object of type Authentication Scheme is selected.

   Click OK

4. Enter a name and a protection level.
5. Select SecurID Template from the Authentication Scheme Type list.
6. Enter the ACE User ID attribute.
7. Click Submit.

   The authentication scheme is saved and can be assigned to a realm.

How to Configure a SecurID HTML Form Authentication Scheme

To configure a SecurID HTML Form authentication scheme, do the following procedures:

1. Review the SecurID HTML Form scheme prerequisites.
2. Configure a SecurID HTML Form authentication scheme.

SecurID HTML Form Scheme Prerequisites

Complete following prerequisites before configuring a SecureID HTML Form authentication scheme:

• For Policy Servers on Windows, the ACE configuration information file (sdconf.rec) resides in the winnt\system32 directory. The VAR_ACE and USR_ACE variables are pointing to the appropriate ACE agent data and prog directories respectively.
• For Policy Servers on UNIX, the sdconf.rec file resides in the <policy server installation dir>/bin directory. Additionally, the VAR_ACE and USR_ACE variables are pointing to the <policy_server installation_dir>/bin, allowing the Policy Server to use API libraries and not the ACE agent.
• A customized .fcc file resides on a Web Agent server in the cookie domain in which you want to implement HTML Forms authentication. CA provides sample .fcc files under the Samples/Forms subdirectory, where you installed your Web Agent.
• A customized .unauth file resides on the Web Agent server.

  Note: The .unauth file is not required if the .fcc file uses the smerrorpage directive.

• A directory connection exists between the Policy Server and the user directory.
• The default HTML forms library is installed. This library handles HTML Forms authentication processing:
  • SmAuthHTML.dll on Windows
  • smauthhtml.so on Solaris

  These files are installed automatically when you configure a Web Agent.

More information:

User Directories

Configure a SecurID HTML Form Authentication Scheme

You can use a SecurID HTML Form authentication scheme to use a custom HTML form to authenticate users logging in with ACE credentials.

Note: The following procedure assumes that you are creating an object. You can also copy the properties of an existing object to create an object. For more information, see Duplicate Policy Server Objects.

Follow these steps:

1. Click Infrastructure, Authentication.
2. Click Authentication Schemes.
3. Click Create Authentication Scheme.

   Verify that the Create a new object of type Authentication Scheme is selected.

   Click OK

4. Enter a name and a protection level.
5. Select SecurID HTML Form Template from the Authentication Scheme Type list.
6. Enter server, target, and ACE attribute information.
7. Click Submit.

   The authentication scheme is saved and can be assigned to a realm.

SecurID HTML Form Support for Re-activating and Verifying SecurID Users

If you protect a realm with the SecurID HTML Form scheme, users who are suspended due to improper logins can attempt to activate their accounts using a number of customizable HTML forms. You can modify the layout and wording of these forms, but you must not modify the tags that gather user information.

The forms provided with the Policy Server include the following:

PWLogin.template

This form is where users enters a username and passcode to login.

PWNextToken.template

This template requests multiple tokencodes to confirm that the user is in possession of a working SecurID token.

SecurID HML Form Support for Activating New User Accounts

The Policy Server uses the following forms when an administer creates a user account, and that user logs in. Through the forms, a user creates a PIN, or has the Policy Server generate a random PIN.

PWSystemPIN.template

For new users, or users whose accounts have been suspended (due to too many invalid login attempts), this template prompts the user to acquire a new PIN. This template accepts the user’s original username and passcode, but instead of granting access to a protected resource, it redirects the user to another form where the user can receive or create a new PIN.

PWNewPINSelect.template

This template allows a user to indicate if the system should generate a new PIN, or if the user wants to enter a new PIN.

PWUserPIN.template

This template allows a user to enter a new PIN. The user must provide a valid username and passcode along with the new PIN. In this template, $USRMSG$ is replaced with instructions for creating a PIN number. For example:

PINs must be between 4 and 8 characters in length.

PWPINAccept.template

This template indicates that a new system-generated PIN has been created. In this template, the system generated PIN replaces the $USRMSG$ variable.

When a user clicks Continue, the user is immediately prompted to log in using the new PIN.