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)
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
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.
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.
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.
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.
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
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.
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.
(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.
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.
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
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
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.
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..
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.
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.
Goto PERMIS Web Site
Goto OpenPERMIS Web Site
Page last updated 23 August 2012