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.

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

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. 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, SiteMinder SecureID authentication schemes require mapping between the ACE and SiteMinder users. This mapping is represented as an authentication scheme object attribute in the 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 SiteMinder:

1. A user requests a resource such as a Web page.
2. The 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 SiteMinder user name to RSA/ACE user name. At this point, the Policy Server does not apply 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 prerequisites are met before configuring a SecureID authentication scheme:

• On Windows Policy Servers, the RSA ACE/Client software is installed on the same system as the Policy Server. For information about supported RSA ACE/Client versions, see the Platform Support Matrix on the Support site.
• If the following are true, be sure to 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.
  • One of the following:
    • ACE is protecting another application, which SiteMinder does not protect.
    • ACE is protecting another non–SiteMinder 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, which is used to set the failover attempts to the ACE server, has been removed.