Laatste update:
About two decades ago IAM (Identity & Access Management) saw the light of day. Traditional firewalls that were aimed at keeping the bad guys out didn’t work very well for promoting online presence of organisations on the Internet and to allow the good guys in.
IAM became a fundamental aspect of information security that ensured the right people had access to the right resources. Just to name two examples: it made sure employees with the right profile could get access to the company resources they needed for their jobs and customers could get access to their banking or shopping accounts.
RBAC
So, after authenticating and identifying the user, it was sufficient to stick some role to the individual and all was clear. This was reflected by the RBAC (Role Based Access Control) security model.
However, soon it became clear that roles were not sufficient.
- An employee could be a salesperson working in a specific region and focussing on a restricted set of products
- A customer could have a bronze, silver or gold profile with associated limitations on the transactions they could execute
Mapping all these attributes onto roles (see example below) pretty soon resulted in an explosion of the number of required roles.
- Role=”sales-be-solpan-ind” represents “role=sales, region=Belgium, product_type=solar-panels, product_category=industrial”
- Resource “product information XYZ” is readable if Role=”sales-be-solpan-ind”
ABAC
Not only did this become cumbersome or even impossible to manage but it also caused a tremendous rise in unauthorised accesses to data.
Fortunately, ABAC (Attribute Based Access Control) came to the rescue. Instead of mapping all combinations of attributes (e.g. role, region, product_type, product_category) onto roles, the authorisation rules were expressed using attribute value combinations.
So, instead of stating:
- Resource “product information XYZ” is readable if Role=”sales-be-solpan-ind”
The Authorisation rule would become:
- Resource “product information XYZ” is readable if “role=sales & region=Belgium & product_type=solar-panels & product_category=industrial”
PBAC
Unfortunately, it was already obvious to integrators that ABAC also had its limitations. But it’s only since concepts like Zero-Trust and Continuous Adaptive Risk Management popped up, that the need for a more powerful authorisation system was recognised, also by analysts.
Simple ABAC rules with distinct and static values for attributes couldn’t cope with these new challenges.
- A salesperson requesting detailed product information of all products at once should probably raise an alarm
- A banking customer performing two valid transactions within a short allowed timeframe but from locations 1000km apart, obviously should be monitored closer
PBAC (Policy Based Access Control) was born. Not only is there a requirement to have a more powerful mechanism to express authorisation rules, also it should allow for attributes to express ranges of values or even real-time values.
- Patient record “ABC” can be updated by doctor “XYZ” if “role=doctor & treating_relation(ABC, XYZ)=TRUE”
Clearly this latter expression cannot be expressed by static data but would require the authorisation engine to access some medical repository on the fly.
But we’re not there yet…
But already we see scenarios that go beyond what basic PBAC can do. In some cases authorisation might rely on some batch or real-time intervention of a person or a system.
- A user must accept some T&C before getting access to the online internet service of an organisation
- An employee must enter some personal data to complete a record in the HR system before being provisioned to the required applications
These are use cases that will require the authorisation engine to have access to a user journey system or governance platform. And this finally brings us to Orchestration. A relatively new concept that will be subject of a future blog.
