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
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.
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.
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.
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.
Page last updated 23 August 2012