Understanding Authorisation Services with Redhat SSO

par | Nov 24, 2017 | Gestion des Identités, SSO

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)

Name: "Default Permission"
Type: "urn:hello-world-authz-service:resources:default

 

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)

Name:  Urn:photoz.com:scopes:album:view

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 »

Name: Any Admin Policy
Realm Role: admin

Example of Client Role

Name: Any User Policy
Name Client Role: Manage Albums  (of client application photoz-restful-api)


Note:
It means that the role "Manage Album" has already been added to the list of possible roles of this application.

 

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

var contextAttributes = $evaluation.getContext().getAttributes();

if (contextAttributes.containsValue('kc.client.network.ip_address', '127.0.0.1')) {
    $evaluation.grant();
}
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:

Name: Album Resource Permission
Resource Type: https://photoz.com/album
Policy: Any User Policy, Any admin Policy
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:

Name: Delete Album Permission
Scope: urn:photoz.com:scopes:album:delete
Policy: Only Owner and Administrators Policy

 

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

 

 

janua
Les derniers articles par janua (tout voir)