The black box challenge

To date, information systems come with authorization code built into the application logic. Programmers model program behavior based on authorization requirements: "If the user does not belong to group A, B or C with read/write permissions, all the options in the Edit menu should be grayed out", "Before initiating transactions of type T, check that the amount does not exceed the current user's authorization level and if it does, exit with an error message", etc. These programming tasks become quite elaborate and in detail only understood by the programmers themselves. From the outside, the inner workings of the application remain unknown â€“ the application logic is seemingly built into a black box. For all you know from the outside, the application could even include backdoors: "if the user is 'bob' then allow anything...".

With Attribute Based Access Control (ABAC), based on the XACML standard, authorization is instead externalized from the application logic:

• The rules that define who can do what, why, when and how are defined in XACML policies.
• The decision making is made by a Policy Decision Point (PDP). It evaluates an XACML request against applicable XACML policies and thus replaces the previous internal application logic.
• A Policy Enforcement Point (PEP) enforces the PDP decision. 

The PEP may reside "inside" the application, in a portal or gateway "in front of" the application or in the data layer "behind" the application. Regardless, where it is placed, it will enforce the response from the PDP, typically a PERMIT or DENY decision.

Scaling with transparency to overcome the black box challenge

Instead of application logic hidden within compiled application binaries, corporate directives are expressed in a logical and readable policy language. Black box authorization is replaced by transparency and full control. Furthermore, policies can be changed as business requirements change without any alterations of the controlled software. The PEP-PDP interaction is also completely transparent to the user and happens "under the hood", wired into the information system itself.

The real value becomes obvious when you consider scaling scenarios. When each application has its own unique authorization algorithm, the black box challenge increases with the number of applications and users. Contrarily, the value of externalized authorization grows with the number of applications and user permissions that are being controlled from a central point.

PEP and PDP deployment

The technical deployment of the core components that interact to achieve externalized authorization may vary:

• PEP components are deployed where they best can intercept access requests. This can be on many different levels within an infrastructure: as extensions of an XML gateway, web server, web access management tool or portal, as embedded components within the running application written in the application's native programming language, as servlets, filters, or http handlers on an application server, as listeners or separate services called by a message queue based on it's orchestration rules, as database proxies intercepting any attempt to retrieve data from a data store, etc. In modern software design patterns with ViewModel concepts, such as MVC or MVVM, PEP components may play a role within multiple layers. Within business objects, a PEP can filter out data so only items for which the user has authorization is retrieved. Within the View rendering part, a PEP can assist in rendering the Graphical User Interface (GUI). GUI components such as menu items or buttons are added/removed or activated/deactivated depending on authorization requirements. 
• The PDP can be deployed to run in-process with the PEP wherever it has been deployed. The PEP/PDP components become a closely linked policy enforcement and policy decision making package but the XACML policies themselves are still authored and maintained outside the application. The PDP reads its policies from an external source, a Policy Retrieval Point (PRP). 
• The PDP can also be deployed as an authorization service of its own within the infrastructure reachable via multiple protocols such as Web Services, JavaRMI, thrift, RESTful deployments for JSON or other HTTP/REST clients, etc. One and the same PDP can thereby service many different PEPs/applications.

For more technical details, see the article on 100% XACML or various entries in the Developer's corner on this web site.