Seamless Integration of PERMIS and Shibboleth Development of
Seamless Integration of PERMIS and Shibboleth – Development of a Flexible PERMIS Authorisation Module for Shibboleth and Apache Server Wensheng Xu, David Chadwick, Sassa Otenko Computing Laboratory, University of Kent, Canterbury, UK 1 July 2005 © 2005 University of Kent 1
Outline § What Shibboleth is proud of § Why Shibboleth need to be further improved § How we integrate Shibboleth and PERMIS § What we have achieved 1 July 2005 © 2005 University of Kent 2
Shibboleth § An architecture to link resource web sites and authentication systems (http: //shibboleth. internet 2. edu) § Based on PKI, multiple parties form a federation in Shibboleth § Can securely transfer attributes between home sites and resource sites (SAML 1. 1) 1 July 2005 © 2005 University of Kent 3
Shibboleth § Authentication is the responsibility of the user's home site w Requests to authenticate the user will be routed back to the home site and take place there § Authorisation is the responsibility of the resource target site w Based on attributes supplied by the home site 1 July 2005 © 2005 University of Kent 4
Shibboleth 1 July 2005 © 2005 University of Kent 5
Shibboleth is proud of: § Web resources and Web services can be shared § Single sign-on is achieved § User privacy is well protected 1 July 2005 © 2005 University of Kent 6
Weaknesses in Shibboleth -- Simple trust model in Shibboleth § The target site relies on the origin site to return the correct attributes § Plain attributes are relatively easy to be tampered with § Only one attribute authority is supported 1 July 2005 © 2005 University of Kent 7
Weaknesses in Shibboleth -- Only basic access control capability § Access control rules are defined in the Apache configuration file § Complex access control rules (RBAC, Dynamic separation of duty, delegation of authority, combination of rules, etc. ) are not supported § The Apache administrator has to manage the access control rules, the resource owner can’t directly specify the rules 1 July 2005 © 2005 University of Kent 8
PERMIS § A PMI software system: w A privilege allocation (PA) component w A policy management GUI w A privilege verification (PV) component w A policy decision point (PDP) 1 July 2005 © 2005 University of Kent 9
PERMIS § Policy-based RBAC is supported · · Policy expressed in XML (compliance with the OASIS XACML standard planned) w Role Allocation Policy (RAP) w Target Access Policy (TAP) w Subject sub-policy w Role hierarchy sub-policy w Source of Authority sub-policy w Target sub-policy w Action sub-policy Complex access control policies supported 1 July 2005 © 2005 University of Kent 10
PERMIS § Decisions are based on roles or attributes § Attributes are stored in X. 509 attribute certificates w Supports multiple sources of authority 1 July 2005 © 2005 University of Kent 11
Shibboleth and PERMIS SAAM User Resource Target Site User Home Site Policy management sub system So. A SHIRE So. A Policy management GUI Authentication System ACs es t bu s tt ri AC A nd a mod_permis Handle Origin Service LDAP Re trie AC ving s( So. A in attrib Attribute pu PERMIS PA sh ut. Authority es sub system PERMIS PA mo an Privilege d sub system de Allocator ) 1 July 2005 SHAR Attributes. PERMIS RBAC and ACs policy Policy LDAP JNI connector Attribute certificate manager WAYF PERMIS PV PERMIS PDP PV/PDP sub system Shib. Authz University LDAPof Kent. Retrieving ACs AC © 2005 AC (pull mode) Storage Site 12
Shibboleth and Apache authentication and authorisation 1 July 2005 © 2005 University of Kent 13
PERMIS SAAM in push mode with X. 509 ACs § The origin site stores digitally signed attribute certificates in its LDAP repository § The target site is willing to trust different attribute authorities at the origin site § So the origin site can to distribute attribute assignments to different managers Shibboleth Origin Domain 1 July 2005 Transfer. ACs © 2005 University of Kent Shibboleth Target Domain RAP/TAP 14
PERMIS SAAM in push mode with plain attributes § The target site trusts the origin’s attribute repository and the origin as a single AA § The origin can store plain attributes in its repository § --- standard Shibboleth Origin Target Domain 1 July 2005 Transfer attributes © 2005 University of Kent Domain TAP 15
PERMIS SAAM in pull mode § The target trusts different attribute authorities elsewhere § PERMIS SAAM should work in pull mode to fetch the ACs itself · An example might be: an engineer is issued with a “certified MS engineer” by a Microsoft accredited agency § Various distributed LDAP repositories may sit in various places and should be accessible by the PERMIS PV component 1 July 2005 © 2005 University of Kent 16
PERMIS SAAM in pull mode Shibboleth Origin Domain Transfer DN Shibboleth Target Domain RAP/TAP 1 July 2005 © 2005 University of Kent 17
PERMIS SAAM with Apache and without Shibboleth 1 July 2005 © 2005 University of Kent 18
User Privacy issues in PERMIS SAAM § When plain attributes are adopted · Standard Shibboleth + PERMIS PDP § When ACs are adopted · · DN must be provided to target site to match X. 509 ACs But DN can be a pseudonym or a group name 1 July 2005 © 2005 University of Kent 19
The PERMIS SAAM Apache Directives § Directives in the Apache configuration file: · · · Permis. Policy. Identifier Permis. Policy. Issuer Permis. Policy. Location Permis. Authorisation Permis. Pull. Mode (optional) Permis. ACLocation (optional) 1 July 2005 © 2005 University of Kent 20
Conclusions: · · · PERMIS SAAM can work fine with Shibboleth + Apache w No Shibboleth source code needs to be modified w More fine-grained access control can be achieved w More flexibility for resource managers PERMIS SAAM can work fine with Apache server Potentially PERMIS can work any authentication systems (providing user DN is released for ACs) 1 July 2005 © 2005 University of Kent 21
Thank you! Question? 1 July 2005 © 2005 University of Kent 22
- Slides: 22