extent of orthogonality in rights management

Traditional Authorisation Flows

After a few conversations, the subject of duties being separated from authorisation in traditional solutions has surfaced as the defacto understanding has become a “decoupled decision/enforcement of a policy from its obligations”. These obligations usually refer to billing/charges. And it is also left to systems and processes upstream from the authorisation component to create and manage the separation of permissions/duties, which limits most of the process results to”ex post facto” (unless the builders of the solution build ad-hoc components perhaps similar functionality as that achievable with ODRL, but that’s not the purpose of this article).

Fig 1. keycloak reference diagram

The typical architecture for authorisation systems leads to integration with the audit layer (operations) as a black box. We could expand that black box slightly and assume that in practice it will look like this:

Fig 2. traditional authorisation flows for duties

Possible different mechanisms could exist to get from the audit/ops layer to the billing, but in practice, most solutions will just get to a data lake for the data to be aggregated or curated at a later stage.

Finally, any orchestration of duties (e.g. “on this action, you have to display a notice of provenance”) is left to the responsible for weaving the solution at the point of interaction with the actor, with only post-mortem ways of verification.

What does this mean to the business?

Multi-staging

The first element that surfaces is that the authorisation flows allow only for billing-based outcomes. The system sends a <actor, action, asset> request, and the flows are separated:

1. The user gets a response to the request for authorisation
2. The system logs an entry,
   • that entry goes to a data lake (either Ops or general)
   • that entry is consumed by the billing systems

There are alternative architectures where the PDP/PEP can “push” the messages to downstream systems, but those would vary per vendor and the integrations turn into custom pieces of work.

Traceability

Tracing turns into a data analysis piece of work, mapping keys and entries from systems to create a cohesive view of “what has happened”. Since each piece is custom-developed, it is now the solution builder’s job to figure out how these make a compelling story for the user.

Wiring

The job of understanding the consequences of actions now is wired into the application, changes to policies and combinations of behaviours require multiple steps:

1. Understand the business requirements and generate a policy(ies)
2. Separate the business policy into authorisation and behaviour
3. Implement the authorisation flows
4. Implement the code for the behaviours
5. Test the entire solution

What allowances are enabled by ODRL?

The first main difference with traditional authorisation solutions is the introduction of prohibitions and duties.

In practice, authorisation systems start with zero-trust and carve subsets of those “things” you can do. As assets, actors and actions create a complex mesh, crafting those intersections where the permissions operate could be difficult to create and edge cases hard to spot.

ODRL also starts from zero-trust, but the introduction of prohibitions makes it simpler for policy managers to create those intersections, rather than sprouting permissions for each case, a prohibition can alter the result of the assessment of a policy. For example:

Permission: [ actor, use, asset ]

Prohibition: [ actor, use, asset, weekends ]¹

We have easily restricted the access to the asset over the weekends, but we can introduce some more sophisticated scenario:

Permission: [ actor, use, asset_1, asset_2 ]

Prohibition: [ actor, use, asset_1, outside_of_the_office ]

Prohibition: [ actor, use, asset_2, weekends ]

In this scenario, we have generated one permission, but the prohibitions are independent for each of the assets.

Since there are no restrictions on the actors, actions or asset numbers in a rule, we could go further and dissect subsets by each element as required. It also becomes easier to read, moving from: “You can do this, in these circumstances” to “You can do this, you can’t do that”.

The ability to relate gatekeeping rules with duties is the next feature that exists in ODRL that is not present in other languages.

Fig 3. relationships amongst rule types

With this, not only can solutions make sure downstream systems don’t receive all interactions with users when authorisation (or denial) takes place during an actor’s session, but it allows to indicate the reasons for duties to be triggered.

There will be circumstances where a single duty can be created as target for multiple permissions/prohibitions and even duties themselves. A good example could be the accumulation of penalty charges when payment hasn’t taken place.

Fig 4. duty-based rights management flows

A mechanism can be created to push duties to a gateway that determines which goes to a billing engine and which should be raised with compliance, and this could also happen in real-time. A use case could be in finance when an attempt of action takes place in a location that isn’t allowed – this can be sent as a “duty to report to a financial conduct authority” from the compliance systems.

Duties can also be pushed back to the actors to create feedback and even provide “functionalities” that are decoupled from the application.

The responses could look something like this:

Fig 5. result of a policy assessment

line 2: was any rule activated?

line 3: what is the result of the evaluation of a policy?

line 4: what is the context of the decision

like 6 / 11: is the rule evaluated a Duty?

line 7 / 12: what is the ULID of the rule

line 8 / 13: any message payload

This sequence allows the developer interacting as an actor to have “richer” possibilities as a provision of user experience. The response messages could include not only “informative content”, but could be a piece of code, or a URL to a script that the front-end will execute (e.g. “duty says that logo of provenance of this digital asset must be shown in the top corner of the screen”).

The problem with mapping business requirements

ODRL expresses more semantic space within the authorisation domain than any other access control language. For most traditional use cases, a mapping to OPA, openFGA or interfacing with systems like keycloak to allocate the permission-based rules can be sufficient.

ODRL can be thought as “any-BAC”, it can be shaped as RBAC, PBAC, ABAC² or Rel-BAC, or if necessary: a mixture of them.

More and more use cases are emerging in today’s digital economy that make it a valuable tool in the arsenal of authorisation:

1. Prohibitions in certain circumstances: as protocols like “robots.txt” become obsolete, systems can trigger compliance checks when a prohibition rule has been activated and a remedy duty has been sent to compliance.
2. Dynamic feedback to the actors via the use of duties have the potential to enrich how shopping flows and content creators “build” their front-end solutions.

1. In this example, you can think of the actor as a placeholder for a role, not a specific user. ↩︎
2. ABAC is theoretically interesting, but in practice policy management could make any solution unworkable ↩︎