-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Before the NIST Role-Based Access Control model[1] (RBAC), we still had a need for what was called: "Dynamic Authorization" (DA). Where arbitrary attributes can be injected into the policy decision. As RBAC gained traction it became broadly applied and worked pretty well for many use cases. But, it didn't satisfy the DA problem.
To get at its root, we must understand the cause — context. What’s contextual data? Anything that differentiates one situation from another for a given decision. e.g., organization, location, account. We experimented with things like rules engines. The DA module would become embedded as a product feature, differentiating it from its competitors. Early attempts to standardize included CORBA's Resource Access Decision[2] (RAD). While being useful within a specific technology stack, i.e. CORBA, the implementation was not widely accepted nor usable outside of it. This pattern repeated and DA remained in the application and couldn't be distilled into a framework. The reasons are numerous, including complexity, performance issues and integrity of the security policy.
So, we largely ignored the problem and of course it recurred in the inception of every project that followed. On the one hand, we have a widely used and a standard model, RBAC. It's simple and covers fundamental security authorization requirements. On the other, complex systems, bound to specific application and technology domains.
I had resigned myself to a practice that always included RBAC as the base authorization layer. That also always had to be enhanced, to provide for the business requirements of the particular application being implemented at that point in time. OK, but not great. Until one day John Tuminaro sprung into the picture. We devised a way to enhance RBAC to accept attributes on a limited basis. It had the advantage of being much simpler than a full ABAC implementation, while solving many of the problems in DA. We believed we had hit the sweet spot between too simple and overly complex.
Since that time the ABAC feature[3] has been integrated into the Apache Fortress[4] authorization system. In the future, it may be expanded with additional attribute mappings, to control things like limits. How many units of the product can be shipped, withdrawn, added, removed, etc.