Configuring Authentication

This chapter covers several authentication topics. These topics include:

• Authentication Flows.

• Password policies.

• User session limits.

Authentication flows

An authentication flow is a container of authentications, screens, and actions, during log in, registration, and other SafeNet Access Exchange workflows.

Built-in flows

SafeNet Access Exchange has several built-in flows. You cannot modify these flows, but you can alter the flow’s requirements to suit your needs.

Procedure

1. Click Authentication in the menu.

2. Click on the Browser item in the list to see the details.

   Browser Flow

   

Auth type

The name of the authentication or the action to execute. If an authentication is indented, it is in a sub-flow. It may or may not be executed, depending on the behavior of its parent.

1. Cookie- The first time a user logs in successfully, SafeNet Access Exchange sets a session cookie. If the cookie is already set, this authentication type is successful. Since the cookie provider returned success and each execution at this level of the flow is alternative, SafeNet Access Exchange does not perform any other execution. This results in a successful login.

2. Kerberos - This authenticator is disabled by default and is skipped during the Browser Flow.

3. Identity Provider Redirector- This action is configured through the Actions > Config link. It redirects to another IdP for identity brokering.

4. Forms- Since this sub-flow is marked as alternative, it will not be executed if the Cookie authentication type passed. This sub-flow contains an additional authentication type that needs to be executed. SafeNet Access Exchange loads the executions for this sub-flow and processes them.

Requirement

A set of radio buttons that control the execution of an action executes.

Required

All Required elements in the flow must be successfully sequentially executed. The flow terminates if a required element fails.

Alternative

Only a single element must successfully execute for the flow to evaluate as successful. Because the Required flow elements are sufficient to mark a flow as successful, any Alternative flow element within a flow containing Required flow elements will not execute.

Disabled

The element does not count to mark a flow as successful.

Conditional

This requirement type is only set on sub-flows.

• A Conditional sub-flow contains executions. These executions must evaluate to logical statements.

• If all executions evaluate as true, the Conditional sub-flow acts as Required.

• If any executions evaluate as false, the Conditional sub-flow acts as Disabled.

• If you do not set an execution, the Conditional sub-flow acts as Disabled.

• If a flow contains executions and the flow is not set to Conditional, SafeNet Access Exchange does not evaluate the executions, and the executions are considered functionally Disabled.

For more detail, go to Realm creation and Authentication flows.

Password policies

When SafeNet Access Exchange creates a realm, it does not associate password policies with the realm. You can set a simple password with no restrictions on its length, security, or complexity. Simple passwords are unacceptable in production environments. SafeNet Access Exchange has a set of password policies available through the Admin Console.

Procedure

1. Click Authentication in the menu.

2. Click the Policies tab.

3. Select the policy to add in the Add policy drop-down box.

4. Enter a value that applies to the policy chosen.

5. Click Save.

   

After saving the policy, SafeNet Access Exchange enforces the policy for new users.

User session limits

Limits on the number of session that a user can have can be configured. Sessions can be limited per realm or per client.

To add session limits to a flow, perform the following steps.

1. Click Add step for the flow.

2. Select User session count limiter from the item list.

3. Click Add.

4. Click Required for the User Session Count Limiter authentication type to set its requirement to required.

5. Click ⚙️ (gear icon) for the User Session Count Limiter.

6. Enter an alias for this config.

7. Enter the required maximum number of sessions that a user can have in this realm. For example, if 2 is the value, 2 SSO sessions is the maximum that each user can have in this realm. If 0 is the value, this check is disabled.

8. Enter the required maximum number of sessions a user can have for the client. For example, if 2 is the value, then 2 SSO sessions is the maximum in this realm for each client. So when a user is trying to authenticate to client foo, but that user has already authenticated in 2 SSO sessions to client foo, either the authentication will be denied or an existing sessions will be killed based on the behavior configured. If a value of 0 is used, this check is disabled. If both session limits and client session limits are enabled, it makes sense to have client session limits to be always lower than session limits. The limit per client can never exceed the limit of all SSO sessions of this user.

9. Select the behavior that is required when the user tries to create a session after the limit is reached. Available behaviors are:

   • Deny new session - when a new session is requested and the session limit is reached, no new sessions can be created.

   • Terminate oldest session - when a new session is requested and the session limit has been reached, the oldest session will be removed and the new session created.

10. Optionally, add a custom error message to be displayed when the limit is reached.