The Scope Authorization Manager allows for OAuth scopes to be used in access decisions, such as which client should be
allowed to read or write to the user managements /Users endpoint. A presented access token to a protected endpoint
will be checked for containing scopes and a decision will be made based on those.
At the heart of the Scope Authorization Manager is the option to configure policies. Each policy is setup on a path for
which actions will be matched and configured rules applied.
An action defines the action that is being performed which requires authorization. The action is checked against the
policies hierarchically, in order of the most specific policy action first moving towards broader and broader policy
actions up to the base policy action. As an example, an admin trying to read the /Users endpoint at the user
management profile will trigger the action um:authorization-actions.user-management.users.admin.read to be checked.
This will be matched against all policy actions on the following paths, in the listed order:
See the Type Reference section on Identities, sc:authorization actions for a complete
reference of available actions with descriptions on what each one entails.
Identities, sc:authorization actions
While each policy defines exactly one action it may contain multiple rules. A rule is setup with one or more scopes and
a decision for what to do when any or all of the scopes are encountered (see applicability any-of, and all-of in
As an example, we might add a rule on the action um:authorization-actions.user-management.users.admin.read for the
scopes scim and admin where we require that both (all-of) the scopes must be present in a provided access
token for the request to be authorized.
Refer to the Scope Authorization Manager configuration options reference
section for a complete list of the available options.
A simple Scope Authorization XML configuration file (applied to the user management profile) could look something like
listing Listing 26:
This XML can be added to the configuration in $IDSVR_HOME/etc/init and reloaded using the normal procedure.
When it is, the above configuration updates the user management profile adding a reference to a scope authorization
manager. This scope authorization manager is then setup in the processing section, with a trivial policy. This
policy applies to an action, which in this case is um:authorization-actions.user-management.users.admin.read; in
plain english a policy for who should be able to access the user management /Users endpoint acting as admin with
read capabilities (listing all users, and so on).
It is possible to use a scopes authorization manager to restrict access to the OpenID Connect user info endpoint. Normally, this endpoint only requires the openid scope. To further restrict this, a scopes authorization manager can be created with additional scopes. If a policy is defined with the as:authorization-actions.oauth.user-read action and configured on the OAuth profile, this will be applied whenever a client requests access to the user info endpoint. This can be seen in the following video: