Personal tools
You are here: Home → GRIA Documentation → Documentation 5.3 → Reference Manuals → PBAC 2 Manual → Overview
 

1. Overview

Up one level
What PBAC is and how it works.

Introduction

PBAC 2 is a dynamic access control mechanism. Its core is a PDP (Policy Decision Point), which answers questions of the form Can <some user> perform <some action> on <some resource>?. The user is described as a collection of credentials. The action and the resource are strings chosen by the calling application. The answer depends on the roles the user has with the resource, the current state of the resource, and the resource's policy.

The diagram below shows a typical PBAC system. Service invocations from users are intercepted by a PEP (Policy Enforcement Point). This collects information about the user, the resource being accessed (the service, or a resource managed by the service) and the action being performed, and asks the PDP whether the access is permitted. The information collection process may involve querying one or more PIPs (Policy Information Points). If permitted, the request is passed to the service, which may register new resources with the system, update a resource's state, or change the access control rules.

The system administrator may use a PAP (Policy Administration Point; typically a web administration interface) to manage the resource policies.

PBAC components

The PEP acts as a connector between the PDP and the rest of the system and is typically very simple. New PEPs can be written as required, and PBAC comes with several, for common situations.

PBAC stands for Process Based Access Control because the access decision depends, in part, on the state of the resource.

PBAC and web services

PBAC is often used for controlling access to web services. Web services create resources and allow users to perform operations with them. When a user tries to access a resource by invoking an operation on a web service, the PBAC system checks that the user is authorised to perform the requested operation on that resource.

The diagram below shows a SOAP service protected by the PBAC system.

  1. A SOAP message from a client is first processed by a Security Handler which checks the digital signature and records the identity of the sender.
  2. The SOAP PEP (provided with PBAC) extracts three pieces of information from the message context:
    • The operation name (from the SOAP body).
    • The primary resource context (from a SOAP header).
    • The X.509 certificate of the sender (from the the security handler).
  3. The PEP passes this information to the PBAC PDP, which checks whether the operation should be permitted given the state and policy of the resource.
  4. If the policy permits the operation, the PEP passes the request to the service itself.
  5. The service may update the resource's state as a result of the request.
PBAC deployment overview

Resources

Conceptually, a service controls a number of resources. Each resource is identified by a unique resource ID, which is a globally unique string (often a URI). Examples of resources include accounts, data stagers, reports and patient records.

Each resource has a process state and a resource type. Different operations on the resource are possible in different states. For example, it is not possible to perform the "read" operation on resources of "data stager" type which are in the "empty" state.

Each service is itself also a resource, with its own distict resource type ("account service" vs "account"). Operations which are not directed at a specific resource (for example, "openAccount") are treated as operations on the service resource, and thus are also subject to access control by PBAC.

Process roles

Not all users are able to invoke all the available operations on a resource. Each possible operation of a given state has a set of process roles which may invoke it. Each individual user has a set of process roles for the resource. The user can only invoke the operation if the intersection of these two sets is non-empty (i.e., if they have one of the permitted roles).

The rules for determining a user's process roles can be changed dynamically, allowing users to delegate access to a resource to others. Delegation is performed by invoking a delegation web service operation, and whether a user can delegate is therefore also controlled by PBAC.

This diagram shows a process type with four states. Inside each state is a list of operations which are valid in that state. After each operation is the set of process roles which are allowed to perform the operation in that state, and a set of states to which that operation may transition. The process roles a user may have are owner, read and readWrite.

Example state model for a data service.

Deployment

A typical in-process PBAC setup is shown below. When a client wishes to use a service, it sends a SOAP message to it. When the message arrives at the server, it is processed by a chain of handlers before the service itself sees it. These handlers ensure that the security policy is enforced, and provide additional information to the service.

A simple in-process PBAC deployment.

In slightly more detail than in the introduction, the steps are:

  1. A SOAP message from a client is first processed by a Security Handler (such as WSS4J) which checks the signatures in the WS-Security header against the message. For each correct signature, it records which elements were signed and which certificate signed them. This list of signatures is attached to the message context and both are passed on to the next handler. If any signature is incorrect the message is rejected. However, whether the signature is from a trusted party is not checked at this point.
  2. The PEP extracts three pieces of information from the message context:
    • The operation QName from the SOAP body.
    • The primary resource context from a SOAP header if present, or the resource context of the service itself otherwise.
    • The X.509 certificate of a signature covering both the body and the context header elements (from the list created by the security handler).
  3. The PEP passes this information to the PBAC PDP, which locks the resource and checks whether the operation should be permitted given the state and policy of the resource. The resource's policy includes cryptographic key material necessary to decide whether to trust the signature.
  4. If the policy permits the operation, the PEP passes the request to the service itself.
  5. The service may update the PBAC policy or the state of the resource as a result of the request. It may also create new resources and register them for protection by the PDP.
  6. When the operation is complete (or the access check fails), the PEP gets the PDP to unlock the resource.

The diagram above shows a simple deployment in which PBAC runs in the same process (JVM) as the service. Invocations in this case are simple Java method calls. It is also possible to deploy PBAC as a stand-alone service and invoke its operations using SOAP calls, as shown below:

A deployment with a separate PBAC service.

Note that in this case the standalone PBAC service has its own security handler and PEP. The adminstrator of the PBAC service sets the PBAC service's own access policy to determines which other services can use it to protect their resources. The check step (3) therefore becomes two checks: one to check that the target service is permitted to use PBAC, and one to check that the user is permitted to access the target service.

The full in-process PDP and the PDP Proxy components both present the same interface to the PEP and to the service, so no code needs to be changed for different types of deployment, only the configuration requires changing.

Next: Service Administrator's Guide