On-Demand Authentication

On-demand authentication (ODA) is a service that allows users to receive on-demand tokencodes delivered by text message, e-mail, or both methods. A tokencode is a randomly generated six- or eight-digit number. You can use ODA to protect resources, such as an SSL-VPN, thin client, or web portal.

ODA strengthens network security by requiring users to present two factors:

• Something only the user knows (a PIN)

• Something the user has (a tokencode)

ODA is easy to deploy because it does not require extra hardware, such as physical tokens. Employees already have and use mobile phones and e-mail accounts.

On-demand tokencodes can be used only once and expire after a specified time period, enhancing their security.

ODA relies on Short Message Service (SMS) or e-mail to deliver the tokencode. If you choose SMS, Authentication Manager sends the tokencode to SMS indirectly through an intermediary. You can customize SMS delivery to use an SMS modem (not included) or a third-party aggregation service.

When a user logs on to an agent with a valid PIN, the system sends a tokencode to the user by text message, e-mail, or both methods. The user is prompted for the tokencode to gain access to the protected resource.

If you use ODA as a primary authentication method, you must install the RSA Authentication Agent software on the resource that you want to protect.

Note:  To use SMS delivery, you must establish a relationship with an SMS provider, and integrate SMS with RSA AM. For a list of supported SMS providers, go to https://community.rsa.com/community/products/rsa-ready/.

On-Demand Authentication User Logon Example

When used as the sole authentication method, on-demand authentication (ODA) is especially suited for people who authenticate infrequently and from a variety of locations, or for people who need network access for a short time only, such as contractors. The following steps show how a user typically uses ODA to access a company web portal:

1. The user opens a browser window and accesses the company web portal.

2. When prompted, the user enters a User ID and PIN.

   A one-time tokencode is sent to the user’s mobile phone, e-mail account, or both.

3. The user enters the tokencode into the browser.

   Note:  The user can also enter the PIN followed by the tokencode, just like a fob-style hardware token.

4. The user gains access to the protected resource.