This article discusses, how the Streaming Attribute Policy Language (SAPL) can be applied to realize complex authorization scenarios by formulating rules for access control in an easy to use policy language implemented using Xtext.
This article covers:
Often applications allow different degrees of access control following role-based concepts (RBAC). Different roles are assigned to individual within the identity management system. This may include hierarchical role concepts.
The number of applications to be managed within an organization is typically increasing over time. Managing access to the different resources correctly results in an explosion of roles. Furthermore a matching increase in complexity in maintaining the integrity of access control as it becomes increasingly harder to define the right roles and correct assignments to individuals or groups.
In addition, role-based mechanisms are often not capable of expressing all access control requirements of a given application domain.
One way to overcome these problems is to employ so-called attribute-based access control (ABAC). Instead of assigning specific permissions to the role attribute of a subject directly, i.e., the entity requesting access to a resource, a set of policies defines rules under which conditions access is granted.
Those rules are based on properties or attributes of the subject, resource, action (i.e., what does the subject want to do with the resource) and environmental conditions.
Fundamentally in ABAC the code path where resources are to be protected (Policy Enforcement Point or PEP) sends the question “May SUBJECT do ACTION with RESOURCE in ENVIRONMENT” to a so-called Policy Decision Point (PDP). This then calculates the decision based on the rules and attributes.
Attributes may be directly attached to the objects in the question or may be retrieved from external sources if specified by the policies in question.
Following such a model has several advantages:
These benefits come at the cost of a certain degree of complexity introduced through the required infrastructure which should be considered on a case-to-case basis.
The primary way of implementing ABAC was to use the XACML standard which specifies an architecture, protocol and XML scheme for specifying policies. Both open source and proprietary XACML implementations exist. However, XACML by itself is a relatively verbose XML-based standard which is difficult to author and to read by a person.
While a standard for a more readable dialect of XACML in form of a DSL exists with ALFA only one proprietary implementation exists.
While XACML as the de-facto standard has its problems in syntax and expressiveness, e.g. parametrization of attribute access, it also is still rooted in a traditional request-response design. Thus, in cases where conditions implying access rights are expected to change regularly, applications must poll the policy decision point to keep up, resulting in latency and scalability issues in access control.
The Streaming Attribute Policy Language (SAPL) introduces an extension to the ABAC model, allowing for data stream-based attributes and publish-subscribe driven access control design patterns, the so-called Attribute-Stream Based Access Control (ASBAC).
The data model of SAPL is based on JSON and JSON Path. A policy enforcement point formulates authorization subscriptions as JSON objects containing arbitrary JSON values for subject, action, and resource. Policies are expressed in intuitive syntax. Here are a few examples of SAPL policies.
Full source of working example projects can be found here on GitHub: https://github.com/heutelbeck/sapl-demos.
Also, this article will not go into the details of the syntax of SAPL but rather explain what the policies do. A full documentation is available under https://sapl.io/docs/2.0.1/sapl-reference.html.
First let us look at policies which are used in a traditional request-response driven system integrated into a Spring Boot application using the SAPL Spring Boot Starter providing a deep Spring Security integration. Given the following repository, the SAPL integration automatically generates policy enforcement points for methods annotated by @PreEnforce or @PostEnforce controlling entry or exit to the method. The SAPL subscriptions are derived by reflection and accessing the principal objects of the runtime.
The next policies are excerpts of a more complete policy set expressed in SAPL.
This policy is a simple implementation of role-based access control for the findById method.
findById is annotated with @PostEnforce so the resource JSON object is a serialization of the return value of the method and this policy transforms the data and blackens substrings of the data for administrators which should not have access to medical data.
This kind of filtering and transformation is not possible with XACML. This is combined with a traditional role-based access control by using the authority attribute of the subject. In case access is granted, the return value of the method will be replaced by the transformed object.
Finally, this policy uses an external data source to fetch additional attributes. In line 16, the policy accesses the patient repository itself and retrieves a list of relatives. And if the user is a relative, it may access, but with certain fields of the dataset removed.
So far, the use of the policies all adhered to the request-response pattern. The following example does use stream-based attributes.
With two custom attribute implementations, this simple policy integrates an IoT physical access control system and a smart contract on the Ethereum blockchain which allow for quasi-real-time enforcement of the rule that only persons on the company premises who hold a certification to access the resource may access it. The angled bracket syntax denotes that the authorization subscription results in a subscription the matching external data stream source.
This article can only scratch the surface of the possibilities for SAPL, its engine and tools.
SAPL was implemented using Xtext, which made it easy to concentrate on designing a user-friendly syntax and runtime instead of reinventing the wheel for DSL processing. It also allowed for developing web-based policy editors for the server applications and significantly reduced the time needed to get from zero to the first running prototype.
SAPL itself is an open source project licensed under the Apace 2.0 project.
Learn more about it on https://sapl.io