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)
Recognition of Authority/Collaboration between
Domains
Support for XACML request/response contexts (now completed)
Support for SAML Attribute Assertions
Authorisation based on attributes from multiple
authorities
Support for Obligations (now completed)
Separation of Duties (now completed)
Authorisation based on Level of Assurance/Authentication
(now completed)
Authorisation based on Reputation
Coordinating Access Control between multiple
PDPs (now completed)
Combining decisions from multiple PDPs
Addition of Log4J functionality (ongoing)
Writing Policies in Natural Language
Autonomic Authorisation
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
As part of the VPMan project,
we are adding 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 will entail building a new SAML repository object and
new SAML parsing object. In addition, the PERMIS code will be able to support
XML signature validation. The SAML repository will communicate with the
AA/IdP over SSL using client authentication, in conformity to the OASIS
profile
Authorisation using attributes from multiple
authorities
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 is developing 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.
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
As part of the EC FW7 TAS3 project we will be integrating
decisions from a reputation service with those from an access control PDP.
The exact mechanism for combination is still to be determined, but it may
be to enhance the PERMIS PDP to connect to the reputation server and to
dynamically retrieve the reputation of an actor automatically. Alternatively
the PEP may retrieve an actor's reputation and pass it as an attribute
along with other ones to the PERMIS PDP. 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
As part of the the EC FW7 TAS3 project, we will be developing
a master PDP that is capable of reading in a combining policy which says
which other PDPs should be called in which order, and how their 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.
Addition of Log4J logging (ongoing)
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 -
first prototype 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.
Goto PERMIS Web Site
Goto OpenPERMIS Web Site
Page last updated 31 March 2008
|
