Oryon Composite Access Control
Introduction
Oryon Composite Access Control, or OCAC for short, is the layer that allows the customization and enforcement of every single piece of the authorization flow.
What does it do?
Firstly, it enforces the Tenant's subscribed components, ensuring that each Tenant has access only to the specific components they have subscribed to.
Additionally, it enables clients to customize their access control settings to meet their unique business requirements. This means that they can define precisely who can access what within their system by allowing the creation of highly flexible profiles containing permissions that can differ not only at the company level but also on specific access-limiting options.
In essence, our access control system serves to address the pivotal question, "Can this User view Contracts, and if yes, what Contracts?".
Fundamentals
Actions
An Action is anything that is possible to do in Constellation. It can be an API endpoint, a button, or a screen. It will always belong to an Application and Module. These actions exist on the Back Office layer and, as a result, are global to all Tenants.
Actions will not be shown to the User, nor are they customizable in any way, as they are a result of the extraction performed by the Azure DevOps release pipelines.
Permissions
A Permission aggregates all actions required to execute what it describes, and it is what the User will be able to use and customize. On the Back Office layer, you are defining what the User can customize.
It is composed of a list of Actions, a Category that will serve to group permissions, a Description that identifies what it enables the User to do, and a non-required Option list. It can also inherit or be inherited by other permissions.
After creation, since they exist on the Back Office layer, they will be available for all Tenants to use and configure if they are subscribed to at least one module defined by the Action list.
Options
Options can be thought of as limiters of access and are what allow us to create custom rules based on context.
For example, in addition to controlling if a User can view contracts, we might want to also limit this permission to ensure that the User only sees their contracts. Meaning if we add a Self-Only option, when returning the contracts, we will check for it and filter out contracts that do not belong to the current User.
For all of this to work, they need to be defined by Oryon in Back Office, meaning every Tenant will have the same options.
Access Profiles
An Access Profile is what will be associated with a User to determine what they can do.
It is composed of enabled permissions and their configurations.
It's for the user to create and maintain as they see fit, and any changes made to it may take up to 5 minutes to be reflected due to the cache's lifetime.
The user will only be able to see and assign permissions that are associated with at least one of their Tenant's subscribed components.
Authorization Flow Diagram
Although this diagram focuses on API Endpoint authorization, it still applies to any type of authorization check, whether it's a button or a view.