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 usernames and passwords reside in the ACE/Server user store and can be changed by ACE/Server administrator. Single-use TOKENCODEs are generated by SecureID tokens.

CA SiteMinder® supports the following SecurID authentication schemes:

SecurID Authentication

This Authentication Scheme authenticates users who are logging in via 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: The SecurId Template authentication scheme will fail to authenticate a user if the user does not use the user directory attribute named 'uid' to map to the userid of the user in the Ace Server. Use the SecurID HTML Forms Template when mapping LDAP directory attributes other than uid to the userid of the user in the Ace Server.

SecurID Authentication with HTML Forms Support

CA SiteMinder® supports a scheme for SecurID authentication that includes HTML forms support. The HTML forms provide a method for users to 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. However, users allowed or required to change their PIN 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 users’ identities through valid RSA Ace/Agents. Further, RSA supports Web Agents and custom Agents. CA SiteMinder® SecurID authentication schemes act as custom ACE/Agents and use ACE/SDK and libraries.

The ACE/Server, however, has its own policy in handling users’ credentials and stores this information in the ACE user store. The policy includes several requirements and limitations for each user, which are defined by the ACE administrator that can be changed 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 TOKENCODE, both the TOKENCODE and PIN are required. In addition, users could be required to set a new PIN while trying to authenticate. Under this "new PIN mode", the old and new PINs are required.

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

In 5.5 SP1, 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 CA SiteMinder®:

1. A user requests a resource such as a Web page.
2. The CA SiteMinder® Web Agent determines if the resource is protected.
3. The Policy Server indicates 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 CA SiteMinder® user name to RSA/ACE user name. At this point, the Policy Server does not apply CA SiteMinder® password policies.
7. The Policy Server forwards the authentication request to the ACE/Server by making a sequence of ACE API calls. It also send 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, presents it 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 login 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 if it:

• Is too long
• Is too short
• Contains alphabetic characters

In the process illustrated in the previous figure authentication includes presenting back-end PIN policy-related messages on the HTML form. The PIN policy validation is done by the SecurID Authentication scheme 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, and 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

In the 5.5 SP1, only the 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 might appear:

If a sample user, Joe, has a PIN that is 5 to 8 digits long but enters a new PIN as "poem", then he would see the following error message:

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

If the next PIN he entered was "novel", he would get:

Your new PIN may not have alphabetic characters.

If the next PIN he entered was "123412341234," he would see.

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

It is possible that, despite the successful PIN validation by the SecureID Authentication scheme, the ACE/Server will 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.

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.

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.