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.
sm1252sp1
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.
2
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.
    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:
Interaction of RSA ACE Server with Policy Server
Interaction of RSA ACE Server with 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.
In the On-Demand authentication mode, if you enter an incorrect Next Tokencode in the first attempt and re-enter the Next Tokencode correctly or incorrectly in the second attempt, a new Next Tokencode is generated. If the second attempt was successful, ignore the new Next Tokencode. If the second attempt failed, use either of the Tokencodes for authentication.
SecurID Authentication Schemes Prerequisites
Complete the following prerequisites before configuring a SecureID HTML Form authentication scheme:
  • For Policy Servers on Windows, generate the ACE configuration information file (sdconf.rec, failover.dat) on RSA Authentication Manager by an RSA Administrator and then copy to the following directory:
    • 64-bit OS: windows/syswow64
    • 32-bit OS: windows/system32
  • For Policy Servers on UNIX, generate the ACE configuration information file (sdconf.rec, failover.dat) on RSA Authentication Manager by an RSA Administrator and then copy to the
    <policy server installation dir>
    /lib directory. Additionally, the VAR_ACE and USR_ACE variables are pointing to the
    <policy_server installation_dir>
    /lib, 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.
    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.
For RSA SecureID Server version 8.0 or higher, verify that an authentication agent has been added in RSA Authentication Manager by an RSA Administrator.
For more information about how to add an authentication agent, see RSA documentation.
Configure a SecurID Authentication Scheme
You can use a SecurID authentication scheme to authenticate users logging in with ACE credentials.
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.
  4. Verify that the Create a new object of type Authentication Scheme is selected.
  5. Click OK.
  6. Enter a name and a protection level.
  7. Select SecurID Template from the Authentication Scheme Type list.
  8. Enter the ACE User ID attribute.
  9. Click Submit.
    The authentication scheme is saved and can be assigned to a realm.
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.
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.
  4. Verify that the Create a new object of type Authentication Scheme is selected.
  5. Click OK.
  6. Enter a name and a protection level.
  7. Select SecurID HTML Form Template from the Authentication Scheme Type list.
  8. Enter server, target, and ACE attribute information.
  9. 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. Do 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 enter a username and passcode to log in.
  • 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 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 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.
Configure SecurID HTML Form Authentication Support for Risk-Based Authentication
RSA Risk-Based Authentication (RBA) for SecurID provides risk-based verification of user identities while preserving the username/password login experience.
To configure the SecurID HTML Form authentication support for Risk-Based Authentication (RBA), the policy administrator and the agent owner must collaborate. This scenario describes all the procedures that both must perform.
How to SecurID HTML Form authentication support for Risk Based Authentication
How to SecurID HTML Form authentication support for Risk Based Authentication
Verify That You Have the Latest  RBA Integration Script Template
The RBA integration script is based on a template that ships with the RSA Authentication Manager. However, because RSA can update the template between releases, verify that you have the most up-to-date template.
Follow these steps:
  1. Download the
    CA Single Sign-On
    RBA integration script template, using this link.
  2. Locate the integration script template that shipped with your RSA Authentication Manager server.
  3. If your server does not have an integration script template, install the template that you downloaded in Step 1. Otherwise, compare the headers of the templates and install whichever one is the newest.
Generate a Custom RBA Integration Script
To generate a custom RBA integration script to deploy on your agents, use the RSA Security Console.
Follow these steps:
  1. Log in to the RSA Security Console and enable RBA for one or more of your agents.
  2. Choose the primary method for agents to use to authenticate users (RSA SecurID or fixed passcode).
  3. To generate your script and download it to a temporary directory, select the
    CA Single Sign-On
    template.
Provide the Custom RBA Integration Script to Agent Owners for Deployment
The custom RBA integration script that you generated in the RSA Security Console must be deployed on each web server that is to support RBA.
Provide the custom RBA integration script to each agent owner and inform them how to deploy it.
Agent Owner Deploys the Custom RBA Integration Script on Each Web Server
Deploy the custom
CA Single Sign-On
RBA integration script provided by the policy administrator on each web server that is to support RBA.
Follow these steps:
  1. Log in to the agent host and locate the default RSA SecurID login template (smpwservices.fcc). The template is located in the /siteminderagent/forms/ directory relative to the agent root.
  2. Open smpwservices.fcc in a text editor, add the following two lines immediately before the </body> tag at the bottom, and save the file:
    <script src="am_integration.js" type="text/javascript"></script> <script>window.onload=redirectToIdP;</script>
    Create a backup of smpwservice.fcc before beginning to edit it and use it to undo the changes if necessary.
  3. Copy the custom  RBA integration script (am_integration.js) to the /siteminderagent/forms/ directory and restart the web server.
Configure Access Gateway for Risk-Based Authentication
The httpd.conf file must be configured to support risk based authentication.
Follow these steps:
  1. Log in to Access Gateway.
  2. Take a backup of the httpd.conf file.
  3. Open httpd.conf and add the following lines of code:
    AliasMatch /*/siteminderagent/forms/am_integration.js "
    accessgateway_installation_path
    /CA/secure-proxy/proxy-engine/examples/siteminderagent/forms/am_integration.js"
    JkUnMount /siteminderagent/forms/am_integration.js ajp13
  4. Save the changes.
  5. Restart Access Gateway.