20 December 2021
Roles have ruled the IAM world for a long time, yet over time were found to be hard to manage and scale; attributes were always out there, but were difficult to adopt. The time has come for Policy Based Access Control (PBAC), a standard that combines the best of both RBAC and ABAC while offering a way to overcome their shortcomings. The first thing that you need to know about PBAC, is that it's not based on any one implementation (XACML, for example), but rather a method to manage access decisions and authorizations regardless of technical implementation. Another important point is that it is capable of scaling and building on existing IAM, while providing an access-control solution according to context-based policies.
PBAC should be agnostic to the consuming application. Policies express the business meaning, and the decision is provided to any consuming application, regardless of its technical implementation. For example, let's say the business policy is: “Traders can execute trades”. Trades are managed in the trading system, that is based on a backend application and web-based frontend. The same access decision must be provided to all layers, in the authorization language it understands. The same policy will address XACML requests/responses, or similar responses to the backend app, and the OAuth token, enabling access to the executing function for the web front-end.
The tough part about ABAC is that you must have attributes, but that’s easier said than done. In many cases, attributes are not that organized nor available. The building blocks of PBAC are the pieces of information and data, etc. that it relies on to make the access decisions. Attributes are only one part of these blocks. The PBAC method offers a flexible solution to its policy building blocks, to enable the usage of any existing data as part of the decision making.
PBAC supports predefined or configured data sources, and enables flexible mapping of identities and authorization data. As part of the adoption phase, it can also enable personally assigned policies to be assigned to identities, which can later be converted to accommodate the identities in an easier to manage way.
Write once, use many times - that's the motto of the policy approach. If the policy states that “users can access their department data”, then HR can go ahead and add as may departments as they wish, the policy will still apply. The same goes to the other side of the policy, the data. A policy stating that “Managers can update their project data”, it does not matter if there are 10 or 100 projects. More layers can be added as needed by the organization, the policy will still remain true, and will be enforced accordingly.
If compliance regulations require you to certify and recertify authorization, check the amount of manual approvals your organization has done in the last six months: Tens of thousands? Probably more…
Instead, think about certifying policies. Policies can reduce the amount of manual approvals by 30% - 80%. In addition, a good PBAC system will present the identities, actions and data that each policy statement applies to - thereby providing the full visibility compliance personnel requires.
Increasingly, companies are dealing with collaboration and employees in diverse geographic locations as well as those that work remotely. That means IT teams have less visibility into and control over identities work practices. By centralizing access control and management PBAC enables IT to define and dictate access control no matter where employees are, what time zone they’re in, what device they’re using, etc.
Likewise, there’s an increase in the number of distributed applications and with that comes more difficulty in managing user identities for those applications. PBAC helps consolidate, control, and simplify access privileges, whether the critical applications are hosted in traditional data centers, private clouds, public clouds, or a hybrid combination of all these spaces.
If you’re interested in learning more about the benefits of PBAC, make sure to read our previous blog on the topic.