RBAC, ABAC, PBAC, OPA, let’s call the whole thing “Auth” Z

(Patrick Parker)

Talking about the basics of RBAC, ABAC, PBAC. We will discuss OPA - open policy agent

RBAC- roles grant rights

• the basic level a minimum. Target object that you’re checking the permissions for. Which rights do you have and for which objects you have right?

• there is a misc standard

• the general flow for authorization - user attempts action => ask for decision=>decision maker (access policies defined here, info about identities and resources managed here)
• local decision-making

• auditor perspective, it’s a black box; there is no centralization of authentication

• support external decision making

• the application is the policy enforcement point

those policies typically rely on external factors

• you can do external authorization with RBAC

Q: Which records can Fritz(user) read? A: You have a relation between the role and the rights.

ABAC- Attribute-Based Access Control

• policies are limited only to the degree imposed by the computational language and richness
• if you have that policy, has to fulfill the requirements in the rule.
• there is no way you can access all of this information during work time

• sounds great as you can right any rule but isn’t practical in reality

• Challenges:
  • risk cannot be measured or managed

PBAC: Policy-Based Access Control “Assignable ABAC”

• e.g. in SAP when you assign access to a role + a client

• in cisco you can have privilege level 6,9, 13.. PBAC Query Type: partial decision –> returns a partial answer; under some conditions

  complete decision => the system doesn’t have to gather any information to make the decision

If you build it, will they call? - no

• commercial support giving that much power is not likely

• there are also technical problems

• stick a gateway, a reverse proxy

  • enforce by calling for

OPA - open policy agent

• provides a high-level declarative language that lets you specify policy as code and simple APIs to offload - policy decision-making from your software
• you can have your OPA pull the JSON sign
• central policy decision making

Cloud-Native OPA Authorization

• ABAC or PBAC policies; makes decisions based on the policies

• you can always do it on a reverse proxy level

I am an app developer, I decide which things need to be protected

Q: What is changed compared to the classical PDP concept? A: It’s like SPML, the JSON doesn’t matter.

• when you’re dealing with a commercialized problem, you need to push the permission down.
• you can only have policies of who should have access and push it down

If your role contains delete then you can delete. Your code changes if the user has the rights to delete, then delete. One step forward if you have resource-based. Being able to delete one purchase order and not the other one.

R: Is this standardized terminology?

P: If you read the academic article, there’s TRBAC, and many other RBACs. It’s an academic standard. This is an apache open source project called stormpath, apache shiro is rezback. What is the flow? From an auditor’s perspective of who can do what, it’s a black box. All apps have that in them and you can’t see or change who has access to do what. That produces security problems.

The biggest step is for apps or commercial apps to support external decision making. app asking can the user do this that looks at the set of policies or information sources. if you can centralize that we have one audit that shows who can do what.

Can Fritz delete for this resource object? Do accountants have the rights to delete purchase order 1?

R: Which orders can Fritz read?

P: In rbac model are relational, so you have the relation from user Fritz and the role and the rights and the role and the resource assignment. in rbac you cant definitely answer for which resources can he have.? we are evaluation runtime policies that are statements. you cant ask that question.

abac - the issue is, where are these attributes, and how can I access them to make a decision quickly? real rule is if you had the data if you’re trying to delete and the company hasn’t been set in emergency lockout and you are on a local network or did MFA with LoA with at least 2and not set out of office and the requested value is not less than 2 and many more rules but it’s hard to pull all of these values at runtime. You hit this crazy rule which requires a lot of attributes.

Abac sounds great but it’s not practical in many situations. You just can’t show all roles that can delete the purchase order 1. SO your auditors will hate you.

Who manages the attributes?

In PBAC, you define if I give this bundle of rights, but I will pick only for site code Germany and Denmark and for device time switch and route. in my PBAC I can pick specific nationalities that only the swiss accountants only swiss and Austrian.

PBAC Rely on the caller to have the data, partial decision or globally you already have it figured out. You get that MFA so every request to PDP. Bottom line, someone has to get the data.

You can easily externalize the application, you can have the PDP ready and policies ready, but the application will never call. Commercial support, giving up power to their systems, they won’t do it.

R: There are also technical reasons. You have to make thousands of decisions per second and it won’t work. How do you really get your policies enforced? Self-enforcement means that you are writing your app to do external stuff. Claims based is not great but it’s that you’re doing a request.

OPA is an open-source, general-purpose policy engine that unifies policy enforcement across the stack. It provides a high-level declarative language that lets your specific policy as code and simple APIs to offload policy decision-making from your software.

How is the authorization for pushing policies to the OPA? OPA can pull and push to the rest endpoint and it can ask for it or you can push and it exposes a rest endpoint as well and it can pop a JSON file, authorization for pushing is? I think it uses service credentials, OAuth.

Instead of having the PDP model, you push he info or having OPa that will push the information but it’s grouped. So have local policy enforcement. When you’re dealing with a commercial SAP, you should push the permission there. It’s only when you’re developing microservices when you will use OPA. it’s all happening locally, where everything is in the application box.