HomeDownloadsUser GuideDevelopment

User Guide: Introduction

This page is a short introduction about PMI, RBAC, X.509 and OpenPermis. For the meaning of the used terms and abbreviations please visit our Glossary.

Five Minute Introduction

PKI and PMI

The primary purpose of a Public Key Infrastructure (PKI) is to strongly authenticate parties communicating with each other. But authentication on its own is not enough. As well as knowing who a remote party is, one also needs to know what action the remote party is authorised to undertake. Thus we also need an authorisation mechanism. Such mechanism is called Privilege Management Infrastructure (PMI). A PMI provides the authorisation function after the authentication function has taken place and has a number of similarities with a PKI.

The X.509 PMI Standard

The primary data structure in a PMI is an X.509 Attribute Certificate (AC). This strongly binds a set of attributes to its holder, and these attributes are used to describe the various privileges that the issuer has granted to the holder. The issuer is called an Attribute Authority (AA) since it is the authoritative provider of the attributes given to the holder. Examples of attributes and issuers might be: a degree awarded by a university, an ISO 9000 certificate issued by a QA compliance organisation, the role of supervisor issued by a manager, file access permissions issued by a file's owner. The AA digitally signs the whole data construct ensuring data integrity and authenticity of the subject-attribute bindings.

Why RBAC?

The X.509 PMI standard does not favour any particular authorisation scheme. Discretionary, Mandatory and Role Based Access Control (DAC, MAC and RBAC) schemes can all be supported. RBAC has the advantage that it can significantly simplify the management of access controls for large numbers of users, since the permissions are allocated to roles rather than to individual users.

OpenPermis

Why is the OpenPermis Framework necessary?

Whilst X.509 specifies

  1. a mechanism for identifying 'subjects', which are entities that can be authorized to perform actions
  2. a language for specifying 'credentials', which allow subjects to delegate the authorising duty to other subjects.

it does not specify

  1. a language for describing 'actions', which are operations with security consequences that are to be controlled by the system
  2. a language for specifying application 'policies', which govern the actions that principals are authorized to perform
  3. a 'policy decision point', which provides a service to applications for determining if an action requested by subjects should be allowed, given a policy and a set of credentials.

These missing features are implemented by OpenPermis.

The OpenPermis Implementation of a X.509/RBAC Authorisation Scheme

The implementation of X.509/RBAC Authorisation Scheme with OpenPermis consists of the following:

  1. An application that needs to know if a given subject is allowed to perform a given action on a given target (aka. Policy Enforcement Point or PEP).
  2. A policy describing which roles may perform which actions on which targets and which Source of Authority may issue ACs (or delegate the issuing). The policy may also contain 'obligations', which are conditions that can be checked only by the PEP.
  3. ACs containing the roles assigned to the subjects.
  4. A certificate identifying the source of authority (aka SOA) that signed the policy and the ACs.
  5. A Policy Decision Point (PDP) having access to the policy and all the certificates. The certificates may reside either on the same file system as the PDP or in an LDAP server.

The authorization process is straightforward:

References

Implementing Role Based Access Controls Using X.509 Attribute Certificates by David W. Chadwick, Alexander Otenko, Edward Ball, IS Institute, University of Salford