Categories
Enterprise Architecture

The Policy Enforcement Point

The Policy Enforcement Point Pattern – XACML, Policy Administration and the Policy Decision Point.

Understanding the Policy Enforcement Point pattern:

  • End-user requests access to an application / service.
  • Request is routed through a Policy Enforcement Point.
  • Policy Enforcement Point transfers the request details to a Policy Decision Point for evaluation and authorisation decision.
  • The Policy Decision Point refers to a Policy Store and possibly a Policy Information Point.
  • Policy is administered through a ‘central’ Policy Administration Point (not shown in Figure 1).
  • The Policy Enforcement Point enforces the decisions of the Policy Decision Point.

This concept draws heavily on XACML – eXtensible Access Control Markup Language

Policy Enforcement Point Pattern

Figure 1 – Policy Enforcement Point scenario

Policy Enforcement Point and XACML

Security Patterns in Practice: Designing Secure Architectures Using Software Patterns (Wiley Software Patterns Series)

XACML defines a number of concepts:

  • Policy Administration Point (PAP) – Point which manages policies.
  • Policy Decision Point (PDP) – Point which evaluates and issues authorisation decisions.
  • Policy Enforcement Point (PEP) – Point which intercepts user’s access request to a resource and enforces PDP’s decision.
  • Policy Information Point (PIP) – Point which can provide external information to a PDP, such as LDAP attribute information.

Benefits of the Pattern

  • The Policy Enforcement Point is a single point of access.
  • Policy is decoupled from applications / services. Policy can be managed independently of applications and services, which can therefore concentrate on providing business value.
  • Auditing at the PDP and PEP is simpler than auditing across many disparate applications / services.
  • Implementation of change is simplified – policies can be administered and deployed to defined architectural functions (i.e. PAP and PDP)
  • As an unauthorised request never gets to the application / service (it is intercepted by the PEP) it is much harder to compromise the application. The same is not true if the PEP and PDP are essentially implemented in the application’s security model.
  • The PEP, PDP, PAP and PIP can be implemented using hardened, accredited components.
  • Context Aware Computing is increasingly important. Context Based Authorisation will be simplified by using decoupled policy management and enforcement.

Threat Modeling: Designing for Security

A good principle to consider is: authorisation requests for applications and services will be handled using a dedicated PEP and PDPs.

Further Reading on Information Security

By Steve Nimmons

Steve is a Certified European Engineer, Chartered Engineer, Chartered Fellow of the British Computer Society, Fellow of the Institution of Engineering and Technology, Royal Society of Arts, Linnean Society and Society of Antiquaries of Scotland. He is an Electric Circle Patron of the Royal Institution of Great Britain, a Liveryman and Freeman of London and serves on numerous industry panels. He is a member of Chatham House, the Royal United Services Institute and the Chartered Institute of Journalists.