Use Case Scenarios

The SafeNet server architecture supports the use of a token-side or a server-side PIN in either QuickLog or Challenge-Response mode. In addition, the application using the API must support challenges, inner/outer window authentication, and static password authentication. The following sections discuss these features in detail.

QuickLog mode is recommended because it simplifies the login experience (and strengthens security) by eliminating the requirement to enter a challenge into a token to get an OTP. QuickLog does not rely on time to remain synchronized with the server. Instead, each time an event-based token is activated, a new token code is generated.

To support localization, SafeNet server returns only necessary data in its challenge messages. The application is required to construct a localized version of it, to display to the client.

For example, SafeNet server would return only 19863257, but the application would display, Please respond to the challenge: 19863257.

Basic Authentication

The communication between the application and the server uses challenge messages and states, similar to the RADIUS protocol. The following scenario shows the most basic interaction between the application and the server:

1. The application issues an authentication request that includes the user name, and a passcode.

2. The server responds with one of nine possible return codes, as outlined in Returned Result.

Challenge-Response Authentication

The challenge message and state attribute issued from the authenticating server are central to the concept of challenge-response authentication, outer window authentication, and server-side PIN changes. This mechanism is employed to authenticate tokens in challenge-response mode in the following manner:

1. The application issues an authentication request that includes the user name, and an empty passcode.

2. The server responds with a challenge message containing a challenge string. For example, Challenge: 19863257, and a state attribute.

3. The authenticating application responds to the challenge by issuing another authentication request that includes the same user name, a response, and the state attribute.

Outer Window Authentication

User authentication through inner/ outer window authentication uses challenge messages and state attributes, similar to the Challenge-Response Authentication. In outer window authentication, users provide a match in a large look-ahead window and respond to a follow-up challenge by providing the exact next OTP from their token. The following sequence illustrates the process:

1. The application issues an authentication request that includes the user name, and a passcode.

2. The server finds a match for the provided OTP in the outer window, and then issues a challenge to the client containing an outer window authentication string, for example: Please re-authenticate using the next OTP from your token, and a state attribute.

3. The authenticating application responds to the challenge by issuing another authentication request that includes the same user name, a response, and the state attribute.

PIN Authentication

SafeNet server supports several PIN types:

• No PIN
• Fixed PIN (token-side PIN validation)
• User-changeable PIN (token-side PIN validation)
• Fixed PIN stored on server
• User-changeable PIN stored on server
• Server-changeable PIN stored on server

The SafeNet server authentication mechanism supports incoming passcodes in the following formats:

• [PIN+OTP]
• [OTP]
• [NEWPIN]
• [StaticPassword]
• [null] - empty passcode to request a challenge

PINs stored on the server can be user- or server-changeable. To accommodate this, leverage the challenge framework in the following manner:

User-Changeable PIN Stored on Server

1. The application issues an authentication request that includes the user name, and a passcode.

2. The server finds a match for the provided OTP and determines that the PIN must be changed.

3. The server issues a challenge to the client containing a PIN change string, for example, Your PIN has expired. Please enter a new PIN and a state attribute.

4. The authenticating application responds to the challenge by returning a new PIN and the state attribute.

Server-Changeable PIN Stored on Server

1. The application issues an authentication request that includes the user name, organization name, and a passcode.

2. The server finds a match for the provided OTP and determines that the PIN must be changed.

3. The server issues a challenge to the client containing a PIN change string, for example, Your new PIN is 628. Please re-authenticate using this new PIN and your next passcode and a state attribute.

4. The authenticating application responds to the challenge by issuing another authentication request that includes the user name, organization name, the new PIN and OTP, and the state attribute.

Static Password Authentication

SafeNet server offers the option of static password authentication, including, enabling the user to change the password. The challenge-response architecture can be used in the following manner:

1. The application issues an authentication request that includes the user name, and a static password.

2. If the user is not required to change the password and it is correct, the server returns access-accept.

3. If the user is required to change the password, a challenge message is issued to the client, for example, Your password has expired. Please enter a new password and a state attribute.

4. If a challenge message has been issued in step 3, the authenticating application responds to the challenge by issuing an authentication request that includes the user name, the new static password, and the state attribute.