Dynamic Authorization

User Authorization is the act of taking a decision whether a user should get access and to a particular application, service provider, function, resource and/or record.

About user authorization

User authorization is often confused with user authentication. Authentication is the act of knowing which user profile is trying to use a service. Many implementations grant a user access as soon as they are authenticated. This is of course a very coarse-grained model for access control.

TrustBuilder fosters the security model that is much more flexibel and fine-grained. In this model, being authenticated is a necessary but not sufficient condition to get access. And even ‘being authenticated' has many flavours, e.g. how strong was the authenticated method used, how long ago did the authentication take place, etc. To maintain the level of confidence in the user authentication, TrustBuilder maintains User Sessions. Any access to a system, an application, a resource, a service provider or an API is determined separately. This is the act of 'authorization’, namely evaluating a policy, within a given user session, and determining whether the user should get access in the given circumstances.

While the result of an authentication is a user session, the result of an authorization is a permit/deny decision. While a user session may be represented by an OIDC id-token in the client app, the permit/deny decision is typically represented by an OAuth2 access token or a XACML3 policy decision.

Policy-based authorization

The act of authorising a user to access something and to do something, is fully policy-driven.

With Policy-Based Access Control (PBAC), we aim:

• To offer centralised policy management, whereby all policies and policy rules are governed and maintained in 1 place, as opposed of being ‘implied’ by different access control systems and applications

• To offer externalised fine-grained authorization, whereby policy decisions happen in 1 place, and not in every application

• To enable transaction authorization, i.e. not only authorization to access an application or a record, but also authorization at the transaction level, for every individual transaction

• To enable consent-driven authorization, i.e. to include the owner’s consent before giving authorization to access a personal record.

The TrustBuilder PBAC model is built to achieve high levels of security, while offering security administrators maintenance at scale and offering users a frictionless environment. While the model embraces RBAC when needed, it avoids the pre-assignment of roles, groups, permissions and other access rights to users. It is this ‘pre-assignment’ that causes security administrators so many headaches: it is labour intensive, difficult to maintain on the long run, requires periodic attestation, and cannot be given in the hands of regular users.

Key elements of the TrustBuilder PBAC model are:

• Policy Engine with no-code declarative policies that take into account user profile attributes, user session attributes and context attributes

• Personas defined at user profile level and selected by the user during a user session

• Delegated Administration that push administration of user profiles and personas to the people that are very close to the user

• User sessions with a risk score that evolves during its lifecycle.

Obtaining policy decisions

A user session has a lifecycle during which multiple authorization requests are made.

Authorization will only be granted during a valid session: a valid session indicates that the user is recognised (identified with a user profile) and authenticated (proven that they are the holder) in some way. Further authorization requests may require the user to strenghten the authentication level (Step Up Authentication).

Whereas the Policy Decision Point is called upon when the user logs and gets a session, multiple access decisions may be made and returned during a single session. TrustBuilder returns such decisions in the form of an OAuth2 access token or as a XACML3 policy-decision result.

How to obtain an authorization (= access decision) from the Policy Engine (aka PDP) described on Policy Model ?

• either as direct request/response adopting XACML as protocol

• or token-based adopting OAuth2 as protocol.

Why token-based authorization?

Token-based Dynamic Authorization has big advantages when implementing authorization at scale; access tokens offer scalability, performance and throughput and reduce the number of API calls for authorization.

Scalability, throughput, privacy and security

1. embody a policy decision that can easily be checked by any PEP without further API calls to a policy engine (PDP)

2. enable intermediate hubs such as an API Gateway or Enterprise Service Bus, to act as PEP on behalf of the back-end API

3. can be reused and thus can be viewed as caching a policy decision, so that the policy decision does not need to be re-obtained for every back-endAPI call.

4. offer better privacy since they do not need to convey personal information throughout the API chain and can be made anonymous.

5. offer better security thanks to its short lifetime and its cryptographic protection compared to than mechanisms that are based on symmetric long-lived secrets such as service accounts, API keys and client-id/client-secrets that can easily become compromised.

Protect against man-in-the-middle

The downside of access tokens, however, is that could be intercepted and be replayed by adversaries. To protect against such man-in-the-middle attacks:

1. access tokens contain information about the requestor and the request so that their re-usability is severely constrained

2. access tokens are typically short-lived with refresh mechanisms to re-obtain fresh access tokens, possibly after re-evaluating the policy

3. access tokens can be revoked when a security compromise is suspected, but this requires a call to the introspection endpoint for real-time verification of the revocation status.