Authorization

The goal of this IAM stack was not to create an authentication and authorization stack, but there seemed to be the need for protecting resources, API's and have coarse and fine grained authorization within the applications.

So therefore, each entitlement that is assigned to a identity, can grant access to resources.

The application works with a opaque token that can be inspected via the 'tokeninfo' endpoint.

curl --location --request GET 'http://localhost:9094/tokenInfo/2ed914d9d81106b9acf6c10d5bbaf9a956b8bce9c3a72bc8869d9a32bc921d5b144b0c645dee9a8704ce9cb47d5151ea0b0d8702461372f0d70aab2fce2eb046a51e09187e81867a58dc093d8f934991e3e895e6ccbb3f986260d6caca53250ffab875ed8619263f4988a763e89ede37034d4174775ee9d21844a0a666dca41d' \
--header 'Content-Type: application/json'

{
    "entitlements": {
        "SNPP": [
            "ADMIN",
            "ENT0005"
        ]
    },
    "firstName": "Homer",
    "lastName": "Simpson",
    "gender": "M",
    "enableMultiFactorAuthentication": true,
    "active": true,
    "validFrom": "1668000157869",
    "id": "http://localhost:9190/api/identity/2012",
    "type": "USER",
    "email": "[email protected]",
    "validTo": "1668003757869"
}

What you see above is that the user has two entitlements in the context of a organisation with the code SNPP (Springfield Nuclear Power Plant).

This token might seem to be sufficient to perform coarse grain authorization.

But sometimes it is necessary to even go deeper on the level of permissions.

Let's see the output of the policy calculation of this user:

curl --location --request GET 'http://localhost:9094/policies/2ed914d9d81106b9acf6c10d5bbaf9a956b8bce9c3a72bc8869d9a32bc921d5b144b0c645dee9a8704ce9cb47d5151ea0b0d8702461372f0d70aab2fce2eb046a51e09187e81867a58dc093d8f934991e3e895e6ccbb3f986260d6caca53250ffab875ed8619263f4988a763e89ede37034d4174775ee9d21844a0a666dca41d' \
--header 'Content-Type: application/json'

....
 {
        "permission": {
            "creationDate": "2022-11-06T14:18:53.906+00:00",
            "createdBy": "INITIALIZATION",
            "modificationDate": null,
            "modifiedBy": null,
            "id": 31,
            "nameSpace": "PERSONIFY",
            "resource": "IDENTITY",
            "action": "READ",
            "name": "PERSONIFY:IDENTITY READ"
        },
        "decision": "ALLOW",
        "policyConditions": null
    },
.....    

The policy is defined by the following triplet:

• permission : the resource and the action

• decision: ALLOW or DENY

• the policy conditions : extra conditions that are applicable on the policy

The reason these policies appear is because they are configured on the entitlement.

This way, by creating new custom entitlements and assign existing or new rules to them, a policy context can be customized.

Note : policy conditions is the functionality where one can define rules to match certain values of the authentication context against the body of the requested entity

e.g : organisation administrators can only update their organisation