Talking about the basics of RBAC, ABAC, PBAC. We will discuss OPA - open policy agent
RBAC- roles grant rights
there is a misc standard
auditor perspective, it’s a black box; there is no centralization of authentication
support external decision making
those policies typically rely on external factors
Q: Which records can Fritz(user) read? A: You have a relation between the role and the rights.
ABAC- Attribute-Based Access Control
sounds great as you can right any rule but isn’t practical in reality
PBAC: Policy-Based Access Control “Assignable ABAC”
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
OPA - open policy agent
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.
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.