1) Overview

Understanding Authorisation Services with Redhat SSO : Authorisation Services is a major key component of an Identity and Access Management Solution.

It allows to define the resources and scopes a user is entitled to (i.e. permission). Like this is possible to protect resources, and also retrict user access according to privilieges (based upon sopes and roles, realm, client application

If nothing is defined, the default is DENY (access to the resource).

In the following section is presented all the key concepts allowing to put in place an Authorisation Service for Redhat-SSO.

2) Components of an Authorisation Service

The main components   of an Authorization Services are:

  • Resources
  • Authorisation scopes
  • Policies
  • Permissions
2.1) Resources

A resource is the entity that has to be protected.
A resource is defined with following piece of information

  • Name (mandatory)
    A human-readable and unique string describing this resource.
  • URI:
    A URI that provides the location/address for the resource. For HTTP resources, the URI is usually the relative path used to serve these resources.
  • Type
    A string uniquely identifying the type of a set of one or more resources. The type is a string used to group different resource instances. For example, the default type for the default resource that is automatically created is urn:resource-server-name:resources:default

Example of Resource  (Keyclock/examples/authz/hello-world-authz-service)

 

2.2) Authorisation Scopes

A resource’s scope is a bounded extent of access that is possible to perform on a resource. In authorization policy terminology, a scope is one of the potentially many verbs that can logically apply to a resource.

It usually indicates what can be done with a given resource. Example of scopes are view, edit, delete, and so on. However, scope can also be related to specific information provided by a resource. In this case, you can have a project resource and a cost scope, where the cost scope is used to define specific policies and permissions for users to access a project’s cost.

An authorisation scope is defined by:

  • Name
  • icon URI

Example: (from photoz-restful-api Authorization Scope)

On this example, the icon URI field is empty

2.3) Policies

Policies indicates who can access to a given resource.

The policy can be based on:

  • Roles (User role, Admin Role …)
  • Rules
  • Java script
  • Aggregate
  • Time
  • User
  • Client

It is possible to tailor all those different policy types according to your needs. Below are illustrated and detailed some specific roles

2.3.1 ) Role Policy

The role policy has to be defined either as:

  • a client Role
  • a realm Role

Example of Realm Role 
(photoz-restful-api Authorisation Policies). Here the role applies to the entire « realm »

Example of Client Role

 

2.3.2) JavaScript Role

The Javascript Role is used to make a test on the user and allows to test specific conditions using a a javascript. For example, with the following script, only users with a given IP are accepted

photoz-restful-api Authorisation Policies

3)  Permission

A permission makes the match between:

  • Resource and policy
  • Scope and Policy

It means that when a match is found the user (satisfying the policy) can access to the resource

3.1) Resource – policy permission match

A resource policy permission is defined by:

  • Name of the permission
  • Resource to protect
  • Policy

Example:

3.2) Scope – policy permission match

This permission allows user to perform cetain type of action.

A scope  policy permission is defined by:

  • Name of the permission
  • Resource to protect
  • Policy

Example:

 

4) Putting it all together – Tailoring authorization Service to your architecture  needs

In the previous section have been highlighted an Authorisation Service is made of, so you can get good grap of what can be used.

Now when coming to real, and designing your Authorization Service architecture policy you need to wonder yourself how to best put in place the tryptic Resources /Scopes , Policies and Permissions with question such as:

  • What are the resources / copes  that are needed to protected
  • What are the policies to be defined to map individual
    • Is it user based
    • Is it role based
  • What are the permission association should be defined betwenn roles/scopes and policy

Once you have sketch out your Authorization Services you can start digging in the technicals of it for implementation.

5)  Pointers

 

 

Olivier Rivat

Olivier Rivat

Senior Software Engineer with over 25 years of experience doing Software Development, Support and Consulting in Identity and Access Management Solutions.
Specialised in IAM (security, access control, identity management) and Open Source integration, settled in 2004 by IAM industry veteran, JANUA offers high value-added products and services to businesses and governements with a concern for Identity Management and Open Source components.
JANUA provides better security, build relationships, and enable new cloud, mobile, and IoT offerings from any device or connected thing.
Olivier Rivat