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