Access and Risk Management

This feature brings access and risk management capabilities to Safenet Access Exchange. This feature authorizes valid users based on user, role, group, times of the day, Regex, client, and client scope after authentication. This approach reduces the overall risk of the system by adding a layer of security after a user authenticates.

This feature complements context-based workflow selection, such as application-level requirements, client based rules, and user base or tenant workflows.

This authorization mechanism is supported for OIDC-based applications only.

Clients and resources

Client - A client is any configured application in SafeNet Access Exchange. For example, Salesforce.

Resource - A resource is any URL or webpage in the application. For example, an admin page or home page.

Setting permissions

A permission is a rule that links a resource (something you want to protect) to a policy (the logic that determines whether access is granted).

Decision strategies

The decision strategy controls the access decision when multiple policies are configured in a single permission. The following decision strategy options are supported:

• Unanimous: Access is granted only if all policies return a positive decision.

• Consensus: Access is granted only if a mojority of policies return a positive decision; a tie results in denial.

• Affirmative: Access is granted if at least one policy returns a positive decision.

Authorizing users

To enable authorization:

1. Go to Clients > Select Client > Settings >
2. Set Client authentication = On.
3. Set Authorization = On.

User policy, role policy, and group policy are not supported for SAS user federation.

Policy modes and strategies

This section describes SafeNet Access Exchange enforcement modes and strategies.

Policy enforcement modes

• Enforcing: Access is denied by default if no policy is associated with a resource.

• Permissive: Access is granted by default if no policy is associated with a resource.

• Disabled: Access is granted to all resources, regardless of policies.

Decision strategy

A decision strategy is required if multiple permisions are configured.

The following decision strategy options are supported:

• Affirmative: At least one permission must evaluate to a positive decision in order to grant access to a resource.

• Unanimous: All permissions must evaluate to a positive decision in order to grant access to a resource.

If you use multiple permissions with Decision strategy = Affirmative, then the resources for which you apply permissions must be associated with at least one scope.

Steps:
1. Create a scope in Client Details -> Authorization -> Scopes.
2. Open the resource in Client Details -> Authorization -> Resources.
3. Associate a scope with the resource.
4. Set Decision strategy = Affirmative on Client Details -> Authorization -> Settings.

The resource will be accessible if at least one of the multiple permissions grants access.

Creating policies

A policy is a rule or a set of rules that define the conditions under which access is granted to a resource.

Time policy

A time policy restricts access based on time conditions. Use this policy to define business hours or temporary access windows, for example.

Only the date range and time range functions are supported. The repeat function is not supported.

To create a time policy:

1. Go to Clients > Your Client > Authorization > Policies > Create Client Policy > Policy Type.
2. Select Time from the policy type list.
3. Enter a policy name and description in the fields provided.
4. Select Not repeat.
5. Select dates and times for when the policy starts and ends.
6. Select the logic state that applies to the policy:
   • Positive
   • Negative
7. Save your changes.

Client policy

This policy ensures that access requests are coming from the configured client only. A client policy can be used to restrict access to specific applications or APIs. This capability is especially useful in emergency or security breach situations, where access from a compromised or suspicious client needs to be immediately denied by applying negative-logic policies.

To create a client policy:

1. Go to Clients > Your Client > Authorization > Policies > Create Client Policy > Policy Type.
2. Select Client from the policy type list.
3. Enter a policy name and description in the fields provided.
4. Select a client to add from the drop-down list.
5. Select the logic state that applies to the policy:
   • Positive
   • Negative
6. Save your changes.

Client scope policy

A client scope policy defines access rules based on the Scope field of the access token payload. For example, openid email profile. Use this policy to control which data a client can access.

To create a client scope policy:

1. Go to Clients > Your Client > Authorization > Policies > Create Client Policy > Policy Type.
2. Select Client Scope from the policy type list.
3. Enter a policy name and description in the fields provided.
4. Select Add client scopes and choose a scope from the list that displays.
5. Select Required if the policy will grant access
6. Select the logic state that applies to the policy:
   • Positive
   • Negative
7. Save your changes.

Regex policy

A regex policy uses regular expressions to define flexible access control rules. With this policy, you can define the regular expressions for:

• Context-based attributes such as jti, iss, aud, typ, azp, nonce, session_state, c_hash, s_hash, sid, acr, allowed-origins, realm_access, resource_access, and scope.

• Identity-based attributes such as sub, name, preferred_username, given_name, family_name, email, email_verified, and custom attributes.

To create a client scope policy:

1. Go to Clients > Your Client > Authorization > Policies > Create Client Policy > Policy Type.
2. Select Regex from the policy type list.
3. Enter a policy name and description in the fields provided.
4. Enter a target claim.
   • This is the name of the target claim in the token. JSON claims use "." for nesting paths and "[]" to access arrays by index. For example, client.address[0].country. For target claims that reference a JSON object, map the first path (for example, client) to the attribute name with the JSON object.
5. Enter a regular expression in the field provided.
6. Select the logic state that applies to the policy:
   • Positive
   • Negative
7. Save your changes.

The Target Context Attributes button is unsupported. Leave it unchecked.

Aggregated policy

An aggregated policy combines multiple policies into a single policy. This function is useful for creating complex access rules based on multiple, individual policies.

To create an aggregated policy:

1. Go to Clients -> Your Client -> Authorization -> Policies -> Create Client Policy -> Policy Type.
2. Select Aggregated from the policy type list.
3. Enter a policy name and description in the fields provided.
4. Select a policy to add from the drop-down list.
5. Select the decision strategy that applies to the policy:
   • Unanimous: Access is granted only if all policies return a positive decision.
   • Affirmative: Access is granted if at least one policy linked to a permission returns a positive decision.
   • Consensus: Access is granted only if a majority of policies return a positive decision. A tie results in denial.
6. Select the logic state that applies to the policy:
   • Positive
   • Negative
7. Save your changes.