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:
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.
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 or users who are not in the NextTokenCode mode. However, users allowed or required to 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 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®:
The PIN can be rejected if it:
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:
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:
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.
To configure a SecurID authentication scheme, do the following procedures:
Be sure that the following prerequisites are met before configuring a SecureID authentication scheme:
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.
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:
The Authentication Schemes page appears.
Verify that the Create a new object of type Authentication Scheme is selected.
The Create Authentication Scheme page appears.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
Scheme-specific fields and controls appear.
The authentication scheme is saved and can be assigned to a realm.
To configure a SecurID HTML Form authentication scheme, do the following procedures:
Ensure the following prerequisites are met before configuring a SecureID HTML Form authentication scheme:
Note: The .unauth file is not required if the .fcc file uses the smerrorpage directive.
These files are installed automatically when you configure a Web Agent.
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:
The Authentication Schemes page appears.
Verify that the Create a new object of type Authentication Scheme is selected.
The Create Authentication Scheme page appears.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
Scheme-specific settings open.
The authentication scheme is saved and can be assigned to a realm.
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 provided with CA SiteMinder®. 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 CA SiteMinder® include the following:
This form is where users enters a username and passcode to login.
This template requests multiple tokencodes to confirm that the user is in possession of a working SecurID token.
The following forms are used by CA SiteMinder® when an administer creates a new user account, and that user logs in. Through the forms, a user creates a PIN, or has CA SiteMinder® generate a random PIN.
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.
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.
This template allows a user to enter a new PIN. It requires that the user provide a valid username and passcode along with the new PIN. In this template, $USRMSG$ is replaced with instructions for creating a new PIN number. For example:
PINs must be between 4 and 8 characters in length.
This template indicates that a new system-generated PIN has been created. In this template, $USRMSG$ is replaced by the system generated PIN.
When a user clicks Continue, the user is immediately prompted to log in using the new PIN.
|
Copyright © 2013 CA.
All rights reserved.
|
|