Dynamic Authorizations

The dynamic authorizations take into account the context of the user and apply for dynamic systems in which the context is an important part of authentication and authorization.

Overview

Without the dynamic authorizations, the user management engine (UME) of AS Java provides only quasi-static authorizations. This way the authorizations of a user are given by assigning him or her to a group or a role. When the user authenticates to a system, the user authorizations are checked every time he or she performs an action. These types of authorizations are called quasi-static, as they are not granted to the user for the entire session. If at some point the administrator removes an assigned group or role, the user will lose all authorizations that are granted by the removed groups or roles.

In dynamic systems, where the context is an important part of the authentication and authorization, static and quasi-static authorizations are not enough as they do not take into account the context of the user. This context can be defined according to the following:

The location that a user is authenticating from.

A user can log on from an internal or an external system.
How many authentication factors a user is using.

A user can use single or two factor authentication.
What credentials a user provides.

A user can authenticate with basic credentials, certificate, token, or others.
The time a user is authenticating at.

The UME roles are extended to offer support for dynamic authorizations. For every role, an administrator is able to set additional attributes called scopes. The scopes of a role are string values that are used to determine if the role should be excluded from the user’s assigned principals. The scopes of a role do not work on their own. They are actually compared with the scopes that are set in the session of the currently authenticated user. If none of the role's scopes are present in the session, the role will be excluded. The scopes in the session are set during the authentication process, and they are based on the current context. For the dynamic authorization to work, the context is therefore evaluated during the authentication of the user, and the appropriate scopes are set in the user’s session.

Note

The scopes, as string values, are case sensitive and can contain only alphanumeric characters and underscores.

The following mechanisms use dynamic authorizations:

One-time password authentication

For more information, see Develop a Script for Context-Based Authorizations.
OAuth 2.0 for AS Java

For more information, see .

Specifics

If no scopes are set for the current session, the dynamic authorizations will be disabled, and the specifics outlined below do not apply.

Upon the first request to acquire the roles of a user or to check his or her permissions, the UME checks all roles assigned to the currently authenticated user. If a role has scopes different to the ones in the session, the role will be excluded. If the role does not have any scopes, the role might be excluded, depending on the scope's check mode. There are two options for this:
- GRANT_ROLES_WITHOUT_SCOPE
  
  Roles without scopes are not excluded, and the user will continue to have them. This is the default mode.
- DENY_ROLES_WITHOUT_SCOPE
  
  Roles without scopes are excluded. This does not apply for roles assigned to the groups Everyone and Authenticated Users.
If the current session contains an empty list of scopes, all roles with scopes assigned to the currently authenticated user will be executed.
An OR check is performed for the scopes of a role.

If at least one scope of the role is present in the current session, the role will not be excluded.
Only roles assigned to the currently authenticated user can be excluded from the current session.

Example
We have a user A that has a role A with a scope A, and a role B with a scope A not assigned to user A. When user A authenticates, and there is no scope A in the current user session, only role A will be excluded. Because role B is not assigned to the currently authenticated user, it will not be excluded from the current session.
The excluded roles from the current session will be excluded for all UME principals (users, groups, roles, or others).

If someone tries to read all roles of any group or user, the result will not contain the excluded roles. Other sessions, even for the same user, will not be affected. Their scopes will be evaluated separately.
The excluded roles for the current session will not have any group or user members.
It is not possible to perform user or group assignments to excluded roles.
Executing code in the Subject.doAs method will not affect the dynamic authorizations.
Changing the scope of a role or the assignments to a role will cause a reevaluation of the excluded roles for all currently authenticated users, which are directly or indirectly assigned to the role.
Changes to the scopes of a role are written to the security audit.
When exporting and importing roles via the UME batch export or import functionality, the scopes set for a role are also transported.
The scopes attribute of roles can be manipulated via a UME Service Provisioning Markup Language (SPML) API.

The scopes of a role can be read, written, and searched with the scopes attribute. For more information about the UME SPML API, see Identity Management Java APIs in SAP Identity Management APIs.

Configuring Scopes

Context

Procedure

Creating scopes

With the actions.xml file, you can create scopes for a role in addition to the existing ones. For more information, see Creating UME Actions.

Example

Sample actions.xml file

<BUSINESSSERVICE>
  <DESCRIPTION LOCALE="en" VALUE="ESSO" />
    <ACTION NAME="Create">
      <DESCRIPTION LOCALE="en" VALUE="Create something" />
      <PERMISSION class="java.security.Permission" NAME="USER" VALUE="*" />
    </ACTION>

    <ROLE NAME="Manage">
      <DESCRIPTION LOCALE="en" VALUE="Manage" />
      <ASSIGNEDACTION NAME="Create" />
      <SCOPE VALUE="WORKDAYS" />
      <SCOPE VALUE="INTERNAL_ACCESS" />
    </ROLE>
</BUSINESSSERVICE>

Adding scopes to a role
1. Log on to SAP NetWeaver Administrator at http://<host>:<port>/useradmin.
2. Select the role you will assign the scopes to.
3. Choose the Scopes tab.
4. Choose the Modify button.
5. Choose the Add button and type the scope's value.
  
  You can also add multiple scopes for this role.
6. Save your configuration.

Example

Donna Moore, as a manager of company A, would like to allow the administrators of the company to manage the company systems during working days, but not during weekends. For this purpose, Donna creates the Manage role and assigns it to all administrators in the UME. To allow administrators to log on only during working days, Donna sets a WORKDAY scope for the Manage role.

When an administrator authenticates, the current context is evaluated. If the day in question is a working day, a scope with name WORKDAY is set in the session. When the administrator performs an action, the system checks the authorizations. At that point, the UME checks all the roles assigned to the administrator and finds that the Manage role has a WORKDAY scope, which is the same scope as the one set in the current session. Because the scopes are the same, the UME grants the role to the administrator, and he or she will be able to perform the tasks in the system. If it is not a working day, a WEEKEND scope is set in the session. Again, when the administrator performs an action, the UME checks all the roles assigned to that user and finds that the Manage role has a scope with a different name. In this case, the UME excludes the role, and the administrator no longer has the authorizations granted by that role.