2. 1 July 2005© 2005 University of Kent1 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

3. 1 July 2005© 2005 University of Kent2 Outline  What Shibboleth is proud of  Why Shibboleth need to be further improved  How we integrate Shibboleth and PERMIS  What we have achieved

4. 1 July 2005© 2005 University of Kent3 Shibboleth  An architecture to link resource web sites and authentication systems (http://shibboleth.internet2.edu)http://shibboleth.internet2.edu  Based on PKI, multiple parties form a federation in Shibboleth  Can securely transfer attributes between home sites and resource sites (SAML 1.1)

5. 1 July 2005© 2005 University of Kent4 Shibboleth  Authentication is the responsibility of the user's home site  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  Based on attributes supplied by the home site

6. 1 July 2005© 2005 University of Kent5 Shibboleth

7. 1 July 2005© 2005 University of Kent6 Shibboleth is proud of:  Web resources and Web services can be shared  Single sign-on is achieved  User privacy is well protected

8. 1 July 2005© 2005 University of Kent7 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

9. 1 July 2005© 2005 University of Kent8 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

10. 1 July 2005© 2005 University of Kent9 PERMIS  A PMI software system:  A privilege allocation (PA) component  A policy management GUI  A privilege verification (PV) component  A policy decision point (PDP)

11. 1 July 2005© 2005 University of Kent10 PERMIS  Policy-based RBAC is supported  Policy expressed in XML (compliance with the OASIS XACML standard planned)  Role Allocation Policy (RAP)  Target Access Policy (TAP)  Subject sub-policy  Role hierarchy sub-policy  Source of Authority sub-policy  Target sub-policy  Action sub-policy  Complex access control policies supported

12. 1 July 2005© 2005 University of Kent11 PERMIS  Decisions are based on roles or attributes  Attributes are stored in X.509 attribute certificates  Supports multiple sources of authority

13. 1 July 2005© 2005 University of Kent12 Shibboleth and PERMIS SAAM User User Home Site Resource Target Site SHIRE WAYF Handle Service SHAR Attribute Authority Attributes and ACs Authentication System Attributes and ACs ShibAuthz JNI connector PV/PDP sub system Policy LDAP mod_permis PERMIS PV PERMIS PDP Policy management sub system SoA Policy management GUI PERMIS RBAC policy Retrieving ACs (pull mode) AC LDAP Privilege Allocator PERMIS PA sub system SoA AC Storage Site ACs (in push mode) SoA ACs Retrieving attributes and PERMIS PA sub system Attribute certificate manager Origin LDAP

14. 1 July 2005© 2005 University of Kent13 Shibboleth and Apache authentication and authorisation

15. 1 July 2005© 2005 University of Kent14 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 Shibboleth Target Domain TransferACs RAP/TAP

16. 1 July 2005© 2005 University of Kent15 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 Shibboleth Origin Domain Shibboleth Target Domain Transfer attributes TAP

17. 1 July 2005© 2005 University of Kent16 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

18. 1 July 2005© 2005 University of Kent17 PERMIS SAAM in pull mode Shibboleth Origin Domain Shibboleth Target Domain Transfer DN RAP/TAP

19. 1 July 2005© 2005 University of Kent18 PERMIS SAAM with Apache and without Shibboleth

20. 1 July 2005© 2005 University of Kent19 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

21. 1 July 2005© 2005 University of Kent20 The PERMIS SAAM Apache Directives  Directives in the Apache configuration file:  PermisPolicyIdentifier  PermisPolicyIssuer  PermisPolicyLocation  PermisAuthorisation  PermisPullMode (optional)  PermisACLocation (optional)

22. 1 July 2005© 2005 University of Kent21 Conclusions:  PERMIS SAAM can work fine with Shibboleth + Apache  No Shibboleth source code needs to be modified  More fine-grained access control can be achieved  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)

23. 1 July 2005© 2005 University of Kent22 Thank you! Question?