IT-Tude.com → Technical Solutions → Solutions → 

Distributed Access Control: XACML-based Authorization Service

Overview

The role of the Authorization (AuthZ) Service is to assist services, typically an enforcement point, in their access control. An enforcement point (or security gateway) can use an associated AuthZ service to extend its authorization capabilities and determine whether a particular access request to the protected business service should be allowed or not.

The Authorization Service is a policy-based, rule-based access control service. It implements the XACML 2 standard as well as the XACML 3.0 draft. XACML, the eXtended Access Control Markup Language is an OASIS standard aimed at defining an access control language to express rich access control rules. More information can be found here.

Policies are made up of a target, rules, and an effect. The evaluation of the entire set of policies, also called reduction, leads the AuthZ service to taking an access control decision (either one of PERMIT, DENY, NOT APPICABLE or INDETERMINATE). Policies can be combined together in policy sets with a set-wide algorithm which defines the effect combination rule (e.g. deny overrides any other decision).

Figure 1: Overview of the Policy Structure

The Authorization Service can be instantiated and contextualized making it suitable for cloud deployment s. It can therefore be offered as a network-hosted service. The instantiation of the AuthZ Service ensures it segregates policy execution and the policy stores on a per instance or context basis. Therefore the very same AuthZ Service can be used in different business contexts with different policies and henceforth reach different decisions.

Within the Security Cluster, a prototype AuthZ Service has been developed. In addition, the cluster offers a BEinGRID-specific enhanced AuthZ Service which builds on top of Axiomatics’s Entitlement Server.

More information on Axiomatics and download at http://www.axiomatics.com/products_evaluation.php

To top

High Level Architecture

The Authorization Service consists of:

  1. an optimized policy decision point for XACML 3.0 including the delegation profile
  2. an advanced GUI: the Policy Administration Point (PAP) which has support for XACML 2.0/3.0 policy creation as well as debugging tools
  3. an SQL-based storage mechanism (e.g. PostgreSQL).
Figure 2: Screenshot of the PAP

Sample Scenario

The following scenario is an extract of a wider scenario that spans across several clusters. In this section, we will focus on the Authorization aspect of the scenario. The application scenario is as follows. An aerospace company, Alpha, is engaged in developing fuel-efficient civil aircraft. The focus is on the wing profile and Alpha is looking into optimising its design to decrease fuel consumption. To achieve this, it will need a set of mathematical algorithms, High Performance Computing (HPC) resources, as well as secure storage sites where to maintain the results.

Therefore, Alpha decides to put together a mini-consortium of smaller companies that deliver the required design & analysis capabilities. The following providers are being looked for:

  1. The first of these provides the design-optimisation algorithms that must be used for exploring in a fast and efficient way the many design-options that need to be generated and compared against the performance requirements of the product being designed.
  2. Alpha then requires HPC facilities to explore these design spaces by executing numerical simulations for each individual design.
  3. Finally, the results of the optimisation need to be stored in a highly secure facility suitable for storing industrial engineering analysis data.\

Alpha will collaborate with three partners: Bêta, Gamma, and Delta as per the following diagram

Figure 3. The scenario’s entities and their overall interactions
  1. An Alpha Aerospace designer looks for a suitable algorithm to process wing data with. He queries the algorithm service at Bêta and retrieves one.
  2. The same designer now takes its raw internal data and pushes it along with the algorithm retrieved in (1) to Gamma Computing where a calculation job is created on-demand and with the appropriate quality of service and level of security.
  3. The calculation job eventually terminates and sends its output to the data store at Delta Storage as specified by Alpha Aerospace’s designer.
  4. The Alpha Aerospace designer can now look up, analyse, and use the data stored in Delta Storage.

We will now focus on the Authorization aspect of the scenario.

Figure 4 - Access Rights Management in Collaboration CE1

 

Delta Storage Administrator, Darren, is ultimately the sole administrator of the data stores Delta rents to customers. However due to the distributed nature of the collaboration, Darren will delegate management rights to administrators in other collaborations. In particular, in step 1, he issues a delegation policy for CE1:

  1. The Alpha Aerospace admin, Alan is allowed to administer access to data owned by Alpha Aerospace for read and remove purposes only.
  2. He can write delegation policies about granting write access on its stores at Delta.

At Alpha Aerospace, Alan realises Gamma Computing needs write access to Alpha’s stores at Delta. Therefore, Alan issues this delegation policy (step 2) for CE1: Gama Computing administrators can write access control policies that only allow write access on Delta stores that belong to Alpha.

In addition Alan needs to administer its own users’ access to the resources at Delta Storage. We have already defined the different user types that exist: in this scenario we will consider that Alpha Aerospace users with role “Analyst” can read; those with role “Designer” can read and write; and those with role “Project manager” can read data and remove data. Alan pushes the corresponding access control policy to the Authorization service (step 3). Note that the contents of the policy are coherent with the contents of the delegation policy written in step 1.

Lastly, (step 4), Gama Computing admin, Graham, grants its calculation processes in CE1 with the right to push data to the stores allocated to CE1 at Delta Storage. These policies will be stored and executed by the Authorization Service at Delta.

To top

Dependencies

The latest version of the Axiomatics Authorization Service requires the following components:

  • Java 1.5 and above
  • a dataBase (either of PostgreSQL or MS SQL Server)
  • Sun Glassfish with the Sun Metro stack
  • Optionally a directory e.g. LDAP which can be used to retrieve identity attributes

There are no other IT-tude.com dependencies. However, the AuthZ Service can be used jointly with the Security Token Service (STS) and the Secure Messaging Gateway (SMG) where the SMG acts as a mediator fetching XACML claims stored in the STS and presenting them to the AuthZ service for evaluation.

An integrated architecture based on the scenario aforementioned is presented hereafter:

Interface

Management Interface

The Management interface allows administrators to:

  • define programmatically new policies
    • root policies,
    • trusted policies,
    • administrative policies,
  • policy stores,
  • work areas
  • segregated PDP instances
  • test policies and debug them
  • export and import policies
  • integrate with an attribute store e.g. LDAP and retrieve attributes
  • define new attributes.

Operational Interface

  • InstanceAccessQuery(): this method is the main one used to ask the AuthZ Service for an access control decision. It takes in a standard XACML access control request and returns the decision along with optional obligations.
  • InstanceTestAccessQuery(): this method is a test version of the previous method.
  • InstanceTraceAccessQuery(): this method is used when simulating access control requests prior to deploying live policies. It produces a trace which lets administrators determine how the AuthZ Service reaches the particular decision (DENY, PERMIT…) it has taken based on the request and the policies it contains. It therefore exposes the reduction process to administrators for debugging and analysis purposes.
  • InstanceTestTraceAccessQuery(): this method is the test version of the previous method.

To top

Further Details

  • Related Common Capabilities: check validity of claims, policy-based access control, security updates, and secure e2e communications.
  • Related Technical Requirements: GS-R1, GS-R2, GS-R3, GS-R5
  • Latest Release Date: 01/04/2009
  • Release Number: 3.1
  • Development Status: mature
  • Programming Language(s): Java
  • Supported Operating Systems: Microsoft Windows XP Professional, Microsoft Windows 2003 Server, Fedora
  • Supported or Required IT-tude.com Components: Supports the secure messaging gateway. Does not require any other component Can be used in conjunction with the STS

To top

Download Component

More information and download at http://www.axiomatics.com/products_evaluation.php