PERMIS An Application Independent Authorisation Infrastructure David Chadwick
Role/Attribute Based Access Control Model Hierarchical Role based Access Control (RBAC) Permissions are allocated to roles/attributes Superior roles/attributes inherit privileges of subordinate roles/attributes Users are assigned role memberships Role members acquire roles permissions Benefits Security Remove a user s roles and all privileges are gone Manageability Users change more frequently than roles Scalability No of roles usually much less than no of users User-Role assignments Role-Privilege (UA) assignments (PA)
In Federations and Virtual Organisations we separate UA from PA In traditional RBAC systems both UA and PA are under the control of a single central authority In VOs we can no longer assume this is the case UA is performed by VO managers and other Attribute Authorities e.g. Government, Health Authorities, Employers etc. PA is performed by the resource owner (always) but some permissions may be delegated to VO managers Leads to the following model
Subject SOA 0 CIS Attribute Authority 0 AR AR=Attribute Repository CIS=Credential Issuing Service CVS = Credential Validation Service PDP = Policy Decision Point PEP= Policy Enforcement Point SOA = Source of Authority 10 0 1a PDP 3 4 5 6 5 6 10 CVS 8 9 PDP 12 Target SOA 1b Subject PEP 7 PEP 14 Target 2 Environment 11 Environment 13 Obligations Service
Open Grid Forum OGSA Authz WG Has worked at standardising the protocols for the various entities to communicate with each other Currently have protocols for PEP to PDP (profile of XACML) CVS or PEP or User to CIS (profile of SAML) PEP or PDP to CVS (profile of WS-Trust) Currently don t have protocols for PEP to Obligations Service CVS or PEP to Attribute Repositories because short term freshly minted authz credentials are preferred
PERMIS Subject SOA Web browser Policy Editor 0 PDP 0 0 CPR ACM 0 0 CPR 0 DIS Attribute Authority 0 8b PERMIS Authorisation System 0 8b CVS ACM= Attribute Certificate Manager CPR=Credential&Policy Repository DIS=Delegation Issuing Service CVS = Credential Validation Service PDP = Policy Decision Point PEP= Policy Enforcement Point SOA = Source of Authority 0 PDP Policy Editor Target SOA 3 4 5b 5a 6a 6b 8a 9 11 12 1 Subject PEP 7 PEP 14 Target 2 10 13 Environment Environment Obligations Service
PERMIS Policy Editor
The Virtuous Circle of Natural Language Policy Specification Human Intention Transcription Virtuous Circle ERROR CORRECTING CIRCLE Improve understanding Human Readable Policy Machine parsing and processing Machine transliteration Machine Processable Policy Diagnostic Display Validation checking
PERMIS Natural Language Policy Editor
Natural Lang Output
Coordinated Decision Making Motivation/Problem Statement Sometimes one access control decision depends upon prior decisions E.g. You can only draw 250 from ATM machines in a day E.g. You are only entitled to use 5GB memory per grid job Decision may depend upon previous decisions at the same or different resources in the distributed system Relatively easy to solve if only one PDP is involved Have a stateful PDP Use existing PEP PDP protocol from all nodes in Grid
Conceptual Solution in Brief Store state information in coordination attributes of a coordination object Introduce a coordination policy for the distributed application (which each site can include as part of its access control policy) Access control decisions will then depend upon values of these coordination attributes [as well as subject, resource, action and environmental attributes] Obligations are used to update these coordination attributes Implement coordination object and attributes in a database service (DB provides stable storage, fast lookup, distribution, replication etc.)
Implementation in GT4 Initiator Submit Access Request GT4 (PEP) Present Access Request Target Subject PIP Action PIP Resource PIP Env PIP 1. AuthZ Decision Request 8. AuthZ Decision Response Other Coordinated PDPs Coordination Database Grid Service PIPs Any PDP G T 4 P E P Coordination Database Service Coordination DB 2. Fetch Coordination Attributes 7. Update Coordination Attributes Coord Policy Coord PIP 3. Add to Request Context 0. Get Attributes Context Handler 4. AuthZ Decision Request Coordinated PDP Any Stateless PDP e.g XACML, PERMIS Coordinator 6. Evaluate Obligations Obligations Service 5. Auth Decision With Obligations
Feature Differences Between PERMIS and Monotonic rule evaluation Fast performance Separation of Duties Secure Audit Trail (SAWS) RBAC based Credential validation Natural Language Policy Editor Standards based Standard policy language Obligations Sun s XACML PDP PERMIS No Sun s XACML No No No No No No No
Current Projects Adding support for attribute aggregation Adding support for an Application Independent PEP and multiple PDPs
PERMIS and SAWS Source forge https://sourceforge.net/projects/permis/ and https://sourceforge.net/projects/saws/ Download everything from http://sec.cs.kent.ac.uk/permis A European defence organisation is currently using PERMIS and is investing significantly in re-engineering and hardening it Contact d.w.chadwick AT truetrust.co.uk OR kent.ac.uk