About authentication support for RSA SecurID

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

ISA Server 2000 Feature Pack 1 introduces the ability to authenticate users, based on authentication credentials from the SecurID product from RSA. In this way, ISA Server can secure Web sites requiring authentication credentials from RSA SecurID.

The SecurID product from RSA enforces a requirement that a remote user must have two factors of authentication to gain access to protected resources. These two factors constitute something that the user knows (a PIN), and something that a user has (a physical token). Neither the PIN nor the token will grant access in isolation from each other; both are required.

When a user attempts to access Web pages that are protected by RSA SecurID, the ISA Server computer, on behalf of the IIS Server that it secures, checks for a cookie. This cookie will only be present if the user has authenticated recently, and is not persistent. If the user's cookie is missing, the user is prompted for a username and PASSCODE for SecurID. This challenge is rendered appropriately to the browser type. If the user is using Internet Explorer, the challenge content type will be HTML. The passcode consists of a combination of the user's PIN and tokencode. The tokencode is displayed on the user's token and changes once every minute. The RSA ACE/Agent® on the ISA Server computer passes these credentials to the RSA ACE/Server® computer for validation. If the credentials are successfully validated, then a cookie is delivered to the user's browser for subsequent activity during the session, and the user is granted access to the content.

For additional information about RSA ACE/Server installation and configuration and authentication concepts, see the documentation, available on the RSA Web site (https://www.Microsoft.com/).

Important

  • It is recommended that you use SSL to encrypt the communication between the client and ISA Server.

Note

  • RSA SecurID is based on technology from RSA Security Inc.

How authentication for RSA SecurID Functions

The RSA SecurID protocol uses standard HTTP messages to authenticate a client. The protocol is a variation of a request-based protocol, wherein the client sends special data attached to each request, in order to be allowed by the server to perform its request.

The following terminology is used here:

  • RSA ACE/Server. This computer retains information about users, groups, hosts, and tokens. For each user, the RSA ACE/Server maintains a list of hosts to which the user can log in, and a login name, which can differ from one host to the other.

  • RSA ACE/Agent. This computer provides Web content, and requires the user to provide credentials for RSA SecurID.

  • Client. Usually, a Web browser to receive Web content.

When a client sends a "GET /x" request to ISA Server, the following process occurs:

  1. The Web filter for RSA SecurID ISAPI authentication intercepts the request, and returns an RSA SecurID authentication form to the client.

  2. The client is required to fill in the form with a login name and a passcode.

  3. The browser uses the HTTP POST method to return the form to the Web filter.

  4. The Web filter for RSA SecurID authentication communicates these details to the RSA ACE/Server, to verify that the user is allowed to access via the ISA Server.
    If the answer is positive, the Web filter returns a response which includes a "Set-Cookie" header to the client.

  5. The "Set-Cookie" header writes a cookie to the browser's memory. When the browser is closed, the cookie will be lost.
    The cookie contains information about the user. This information is signed with a secret known only to ISA Server. This means that the cookie cannot be modified by any other users.

  6. The response contains a "Refresh" header, which instructs the browser to resend the original "GET /x" request to the server.

  7. When the Web filter receives a request with a cookie, it verifies that the cookie is valid, by checking:

    • the expiration time

    • IP address

    • signature (to ensure that the data was not tampered)

    If all checks passes successfully, the request is passed to any other installed Web filters on ISA Server and then, to the Web Proxy service.

  8. ISA Server tries to request the object, and the object is sent back to the client.