PERMIS Project Web Site

PERMIS Contents


Essentials Integration Projects Documents Developers Get Involved
PERMIS Development Plans

Development Plans for PERMIS and OpenPERMIS

Now that PERMIS is Open Source and anyone can contribute code to it, we thought it would be best if we told you about our development plans and what you can expect us to be adding to PERMIS in the coming months and years. This will avoid duplication of effort on you part.

Dynamic Delegation of Authority (now completed - the DIS)
Recognition of Authority/Collaboration between Domains (suspended)
Support for XACML request/response contexts (now completed - standalone Authz server)
Support for SAML Attribute Assertions (now completed - enhanced CVS)
Authorisation based on attributes from multiple authorities (now completed - Trusted Attribute Aggregation Service)
Support for Obligations (now completed. In PERMIS PDP)
Separation of Duties (now completed. In PERMIS PDP)
Authorisation based on Level of Assurance/Authentication (now completed. In PERMIS PDP)
Authorisation based on Reputation (you can plug in a reputation based PDP to the standalone Authz server)
Coordinating Access Control between multiple PDPs (now completed)
Combining decisions from multiple PDPs (now completed - standalone Authz server)
Addition of Log4J functionality (now completed)
Writing Policies in Natural Language (now completed - Policy Editor)
Autonomic Authorisation (active project)
Adding sticky policies to clouds (active project)
Dynamic support for new AAsIDPs (active project)

Dynamic Delegation of Authority (DDOA) - now completed

This allows any authorised site manager (SoA) to issue attribute certificates to his staff and for them to be trusted to delegate their attributes (or roles) to other staff, without the target site needing to update its policy. (Release 1 of  PERMIS supported static delegation of authority, whereby only the site managers (SoAs) are trusted to issue attribute certificates and their staff were not allowed to delegate their attributes further). DDoA is being implemented in two phases.

Phase 1 - Now completed - we have released a Delegation Issuing Service. A DIS delegates attribute certificates to delegatees on behalf of users (delegators) whilst simultaneously enforcing the role allocation (or delegation) policy of the delegating site. For a fuller description of the DIS, please read the paper presented at the 2005 NIST PKI Workshop. For a demo of the DIS click here.

Phase 2 - Now completed. The PERMIS PDP can now validate attribute certificate chains as well as fetch any additional attribute certificates that might be needed in order to validate the user's delegated attributes up to a trusted SoA.

[back to top]

Recognition of Authority (RoA) and Collaboration between Domains

This will allow one target domain to recognise another collaborating domain and to dynamically recognise the attribute certificates/assertions issued by the remote domain. The model is specified in the paper

“Recognition of Authority in Virtual Organisations” by Tuan-Anh Nguyen, David Chadwick and Bassem Nasser. LCNS 4657, Trust, Privacy & Security in Digital Business eds Costas Lambrinoudakis, Gunther Pernul, A Min Tjoa. Sept. 2007, pp 3-13

The administrator of a remote domain will be recognised and trusted to administer some limited portions of the local policy (such as role mappings i.e. saying which roles in his domain should map into the local roles of the target domain; and role assignment policies i.e. saying who is trusted to assign which remote roles to whom). RoA will be implemented in two phases, representing simple and complex recognition of authority. Note that static RoA has been supported since PERMIS release 1, in which the target's SoA can add to his local policy the names of the trusted remote SOAs and the attributes from the remote domains that are recognised in the local domain.

Phase 1 will release simple RoA. The PERMIS PDP/CVS will be able to perform role mappings, and map remotely issued roles into roles known to the local domain. We will update the PERMIS policy and Policy Management GUI to support this feature.

Phase 2 will release complex RoA. A trusted remote administrator will be able to add additional role mappings, target access policies and role assignment policies for the remote administered roles into the policy of the target site. This will require an adminstrative PEP to be built, that will validate the remote administrator and ensure that he does not overstep his delegated privileges.

This work will be done as part of the EC FW7 TAS3 project.

[back to top]

Support for XACML request and response contexts - now completed

The interface to the PERMIS PDP has being enhanced to support the XACML request context and to return the XACML response context. This will allow sites to plug in a PERMIS PDP where an external XACML PDP is required. The interface will conform to the XACML authorisation profile being developed by the Global Grid Forum OGSA Authorisation working group. This will be of interest to sites that want to support features that are not currently supported by XACML, such as dynamic delegation of authority and Separtion of Duties. It will also allow sites to support RBAC polices in a natural and intuitive way by using the PERMIS policy editor. The final release wont be made public until the OGF OGSA Authz WG specification has been published.

[back to top]

Support for SAML attribute assertions - now completed

As part of the VPMan project, we have added support to PERMIS for it to pull SAML attribute assertions from an attribute authority/Identity Provider or to be pushed SAML assertions by the PEP. This entailed building a new SAML repository object and new SAML parsing object. The CVS can now validate SAML assertions as well as X.509 ACs.

[back to top]

Authorisation using attributes from multiple authorities - now completed

Users typically have attributes issued by multiple unrelated authorities, for example, degree certificates, professional memberships, credit cards, frequent flyer cards etc. They can typically use these in any combination with service providers. However, when we migrate to the electronic world, if a user wishes to present a selection of his attribute certificates issued by different authorities, in order to be authorised for a particular task, currently this is not possible if the user is known by a different identity by each of these authorities (or Identity Providers). The Shintau project developed a solution to this problem, to allow a user to link together his different attributes (or identities) and to use these in varying combinations with different service providers.EC FW7 TAS3 project continued this work, and we now have a Trusted Attribute Aggregation Service. You can perform a live demo here

[back to top]

 Support for Obligations - now completed

As part of the Nexor funded Secure Role Based Messaging project, we added obligations to the PERMIS decision engine and Policy Editor. This feature allows resource owners to insert obligations into their access control policies, requiring the application to enforce obligations on the user's access request prior to or after granting access to the resource. This may be used in secure role based messaging to help to enforce the message sender's policy, such as "for your eyes only", "keep in your archive" etc. Obligations are also being used to coordinate access control decision making between multiple PDPs in a grid, and to enforce the user IDs that grid jobs must run under. The PERMIS policy schema defines an obligation to be any XML elements and to have an obligation ID attribute. XACML obligations therefore conform to PERMIS obligations, but PERMIS will allow obligation schemas that XACML will not allow.

[back to top]

Separation of Duties (SoD) - now completed

SoD will stop users with conflicting roles from exercising them, even across multiple sessions. Examples of conflicting roles are examiner and student, or buyer and finance clerk. SoD will be implemented in two phases.

Phase 1 implemented a secure audit web service that securely records all access control decisions that have taken place. This is necessary in order to produce a stateful PDP that can remember which roles a user has already invoked.

Phase 2 implemented dynamic separation of duties. The PERMIS policy and PDP have been enhanced to allow SOD policies to be defined and enforced. The PDP uses the secure audit service to remember in which context a particular action was granted to a user, so that if another conflicting action is subsequently requested by the same user, then (s)he will be denied access.

[back to top]

Support for Authorisation based on Level of Authentication/Assurance (FAME-PERMIS project) - now completed

As part of the FAME-PERMIS project,  we have upgraded the PERMIS Policy Editor (to v2) to allow the level of authentication to be specified as an attribute upon which authorisation decisions can be made. The LOA attribute can be specified as a hierarchical attribute, with values in the range 1-4, according to the NIST specification, so that if a particular LOA is required (say Level 2) then a user who authenticates at Level 3 will automatically qualify. FAME stores the LOA as an LDAP attribute so that Shibboleth can pass it to the PERMIS PDP along with all the other attributes. Policies can then be written to give different access rights to users depending upon how they were authenticated. The first version of FAME-PERMIS has already been delivered and a demo is available as described below.


The demo web site comprises 5 arial photographs: a publicly available low resolution view of Didcot powerstation, and four more progressively higher resolution views accessible only to authenticated users with LOAs from 1 to 4, with LOA 4 having the highest resolution view. When you try to access any of the protected views you will be redirected to the Shibboleth Where Are You From Service. You should select rpc56 @ University of Manchester, which will redirect you to the FAME login page at Manchester. The following username/password pairs have been established for testing:

(1) kerbuser/kerbpasswd for Kerberos, gives an LOA of 2
(2) ldapuser/ldappasswd for LDAP authentication, gives an LOA of 2
(3) testuser/testpasswd for  basic un/pw authentication gives an LOA of 1.

A PKI certificate is needed for LOA 3 and a hardware token is required to obtain LOA 4. The demo is available here.


This demo web site comprises three sets of the 5 arial photographs described above. 5 pages are protected by PERMIS authorisation as described above, 5 by GridSite authorisation, and 5 by both GridSite and PERMIS authorisation. In order to access the first set of 5 pages you need the Permis Role1 attribute. In order to access the GridSite pages you need the GridSite RoleX attribute, and in order to access the last 5 you need both the Permis Role1 and GridSite RoleX attributes. In addition, the LOA attribute is used to decide which of the 5 pages you can see. This demo shows that PERMIS and GridSite authorisation can be used separately or together on the same web site. This demo is currently being set up and will be available shortly
[back to top]

Authorisation Based on Reputation of Requestor - now completed

As part of the EC FW7 TAS3 project we integrated decisions from a reputation service with those from an access control PDP. The Technische Universiteit Eindhoven built a modified XACML PDP that based its decisions on the reputation of the requestor, and we built the standalone authorisation server to call multiple PDPs and combine the results. In addition, the PERMIS Policy Editor v2 already supports adding reputations to access control policies, and the PERMIS PDP supports authorisation decision making based on an actor's reputation, so that it is possible to give more privileges to actors with higher reputations.

[back to top]

Coordinating Access Control Between Multiple Distributed PDPs - now completed

As part of the EPSRC Distributed Programmable Authorisation project, we have developed a way of specifying a high level authorisation policy for a distributed application, such as a grid or VO application, and of automatically decomposing this into a set of resource specific policies for each resource PDP in the distributed application. We can then coordinate decision making throughout the distributed application, so as to be able to enforce policies of the type "only £250 may be drawn per person each day from ATMs" or "no more than 20GB of memory can be consumed throughout the grid by a distributed application". This has been integrated into Globus Toolkit v4

[back to top]

Combining Decisions from Multiple Distributed PDPs - now completed

As part of the EC FW7 TAS3 project, we developed a master PDP that is capable of calling multiple PDPs and reading in a conflict resolution policy at start-up which says which other PDPs should be called in which order, and how the decisions should be combined together to reach an overall authorisation decision. Other PDPs will typically be privacy protecting PDPs, trust decision engines and access control PDPs.

Possible Future Enhancement: Support for dynamically provided conflict resolution policies

[back to top]

Addition of Log4J logging - now completed

In order to make it easier for administrators to install PERMIS, and for PERMIS to log the actions of users who access PERMIS protected resources, we have added the Log4J package to the various components of PERMIS. The current release of PERMIS contains log4J logging and logging is gradually been phased into all our software.

[back to top]

Natural Language Expression of Authorisation and Privacy Policies - now completed

The EPSRC Easy project and the EC FW7 TAS3 project will allow managers to specify authorisation and privacy policies in controlled natural language, and for the software tool to convert this into an XML policy ready for driving a PDP. The tool will also convert the policy back to natural language so that the manager can compare the machine's understanding of his policy to his own. The natural language processing is based on the CLOnE ontology engineering language from the University of Sheffield, part of the General Architecture for Text Engineering (GATE) software suite. The first prototype of this is now included in the PERMIS Policy Editor, from release 4.0.15 onwards. We eventually plan to produce XML policies for both XACML and PERMIS PDPs..

[back to top]

Autonomic PERMIS

Imagine a PERMIS PDP that can react to the environment, and change policies according to the prevailing conditions. We are currently experimenting with integrating a management interface into PERMIS so that management commands/alerts can be sent to it and it will change its behaviour as a result. Typical commands might be to increase or decrease the level of logging, or to add new or remove existing policy rules.

[back to top]

Adding sticky policies to clouds (active project)

The standalone authorisation server is capable of storing a user’s sticky privacy policy, and returning it when the user’s data is transferred to another site. As part of the EPSRC funded “Sticky Policy Based Open Source Security APIs for the Cloud” we are adding this feature to the Open Stack open source cloud system. We also plan to allow the sticky policies to be split and merged when the associated data is split or merged.

[back to top]

Dynamic support for new AAs/IDPs (active project)

Currently the set of AAs and their attributes has to be known by the credential validation service when PERMIS starts up, as these are configured into the PERMIS policy. But what if PERMIS gets an unknown attribute from an unknown AA? Currently it is discarded. In future, the PERMIS CVS will make a call out to a trusted ontology server, which will inform the CVS if the unknown attribute is equivalent or superior to a known and trusted attribute, in which case it will be granted the permissions of the latter.

[back to top]

Goto PERMIS Web Site

Goto OpenPERMIS Web Site

Page last updated 23 August 2012

Last updated 20 July 2011