Experiences in federated access control for UK e-Science


Published on

A presentation by John Watt for the Eduserv Symposium 2009 in London.

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Experiences in federated access control for UK e-Science

  1. 1. Experiences in Federated Access Control for UK e-Science John Watt EduServe Symposium 2009 , London May 21 st 2009
  2. 2. Overview <ul><li>Some basic concepts </li></ul><ul><li>NeSC Projects </li></ul><ul><ul><li>GLASS </li></ul></ul><ul><ul><li>SEE-GEO </li></ul></ul><ul><ul><li>SPAM-GP </li></ul></ul><ul><ul><li>Shintau </li></ul></ul><ul><li>Challenges and Questions </li></ul>
  3. 3. Interfacing Technologies Authentication: Who are you? Authorisation: What can you do? VOMS INDIVIDUAL ORGANISATION ?
  4. 4. Role Based Access Control <ul><li>A method of simplifying access control </li></ul><ul><ul><li>Instead of a “name to privilege” mapping </li></ul></ul><ul><ul><ul><li>e.g. a nightclub guest list </li></ul></ul></ul><ul><ul><li>We create a user-held privilege credential </li></ul></ul><ul><ul><ul><li>e.g. a superstore discount card </li></ul></ul></ul><ul><ul><li>Access Policy is now expressible in a single statement </li></ul></ul><ul><li>Several software solutions </li></ul><ul><ul><li>PERMIS (probably) most generic </li></ul></ul>Guest List All Card Holders Guest List Person 1 Person 2 …… .etc…… Person 32637 Person 32638 …… .etc……
  5. 5. Digital Certificates <ul><li>Digital Certificates encapsulate user information in a digitally signed credential </li></ul><ul><ul><li>Contents can be viewed, but not changed </li></ul></ul><ul><ul><li>Digital signature verifies who signed it </li></ul></ul><ul><li>National-scale Grid resources demand a credential of this type, issued by their own certification authority (a CA) </li></ul><ul><ul><li>With its own registration procedure, guidelines etc </li></ul></ul><ul><ul><li>MyProxy tool allows automatic generation of these certificates </li></ul></ul>
  6. 6. Attribute Certificates <ul><li>Combines Digital Certificates with Role-Based Access Control </li></ul><ul><ul><li>An Attribute Certificate (AC) is a digital certificate with role/privilege information embedded inside it. </li></ul></ul><ul><ul><li>May be held by organisation OR user </li></ul></ul><ul><li>DAMESProjectDirector </li></ul><ul><li>NeISSProject_investigator </li></ul><ul><li>MIMASCensusDataUser </li></ul><ul><li>EDINA_SEEGEO_RA </li></ul><ul><li>etc….. </li></ul>
  7. 7. GLASS – Authentication <ul><li>Each member of the University has a unique identifier (GUID) </li></ul><ul><li>User logging in with this GUID successfully is authentic University member </li></ul>University Registry IdP GUID +password GUID query Authenticated
  8. 8. GLASS – Authentication and Authorisation <ul><li>Departments push user roles/attributes (green) to Registry database </li></ul><ul><li>Roles/attributes can be asserted by the Identity Provider on behalf of each department </li></ul>University Registry IdP GUID +password GUID query Authenticated + Attributes Physics Engineering Attributes
  9. 9. GLASS – Authentication and Authorisation <ul><li>Departments store user information under common GUID (dashed lines) </li></ul><ul><li>Roles/Attributes (green) can be asserted by the Identity Provider on behalf of each department i.e. Multiple Attribute Authorities </li></ul>University Registry IdP GUID +password GUID query Authenticated + Attributes Physics Engineering
  10. 10. GLASS - Outcomes <ul><li>Pros </li></ul><ul><ul><li>Linkage to established registration process ensures maximum authenticity of users </li></ul></ul><ul><ul><ul><li>No extra user management </li></ul></ul></ul><ul><ul><li>Campus credential well known by user </li></ul></ul><ul><ul><ul><li>Less likely to forget passwords </li></ul></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Single AA model is unworkable for a large institution </li></ul></ul><ul><ul><li>Multiple AA model requires reconfiguration of deployed IdP </li></ul></ul><ul><ul><ul><li>Difficult to negotiate for a live institutional IdP </li></ul></ul></ul><ul><li>Infrastructure suitable for intranet </li></ul><ul><ul><li>Departmental roles/attributes should only really be relevant to on-site resources </li></ul></ul><ul><ul><li>GLASS applied to Moodle, WebSURF (online records system) at Glasgow by deploying Shibboleth Service Provider </li></ul></ul>
  11. 11. N-Tier ‘Problem’ <ul><li>University says my name is A </li></ul><ul><li>National Certificate Authority says my name is B </li></ul><ul><li>Unsolved (yet) linkage method </li></ul><ul><ul><li>The way digital certificates are made places restrictions on how they can be propagated </li></ul></ul><ul><ul><li>This problem informs a lot of NeSC security projects (indirectly and directly) </li></ul></ul><ul><li>Problem most visible when working with portals accessing back-end Grid Services </li></ul>GUID /c=uk/o=eScience/ou=Glasgow/L=Compserv/CN=john watt B A
  12. 12. SEE-GEO – Portal-based Static Security <ul><li>Geolinking Service (GLS) Portal with in-portal centralised user management </li></ul>GLS
  13. 13. SEE-GEO – Current Shibboleth-based security <ul><li>Separate Shibboleth-protected (dashed line) web pages </li></ul><ul><li>Extraction and staging is a manual process (No auto GLS) </li></ul>
  14. 14. SEE-GEO – Distributed User Management <ul><li>User registers with EDINA-controlled Attribute Authority </li></ul><ul><ul><li>Digital certificate “DN” used as user identifier (extracted from MyProxy) </li></ul></ul>GLS EDINA Attribute Authority EDINA-Signed Role Certificate DN
  15. 15. SEE-GEO <ul><li>Geolinking Service (GLS) Portal is Shibboleth protected (dashed line) </li></ul><ul><li>Web Service Accessor Functions allow Role Based Access Control on EDINA and MIMAS services (EDINA highlighted in this slide) </li></ul>GLS WSAF EDINA Attribute Authority User Check Similar Manchester Setup DN
  16. 16. SEE-GEO Outcomes <ul><li>Pros </li></ul><ul><ul><li>Secure , Dynamic data linkage is now possible </li></ul></ul><ul><ul><li>GLS Portlet can be deployed anywhere </li></ul></ul><ul><ul><ul><li>We have back-end service security now, whereas before all the user management was in the portal </li></ul></ul></ul><ul><ul><li>Centre can retain total control of user attributes and access policy </li></ul></ul><ul><ul><ul><li>When centre controls attributes, the flow of information is reduced (desirable?) </li></ul></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Centres must adopt extra technology </li></ul></ul><ul><ul><li>Users must have access to a digital certificate </li></ul></ul><ul><ul><li>Digital Certificate handling may break CA rules </li></ul></ul>
  17. 17. SPAM-GP - SCAMP <ul><li>Registration of a Service Provider with UKAMF builds trust relationship with ALL Federation Identity Providers </li></ul>SP etc… IdPs Register
  18. 18. SPAM-GP - SCAMP <ul><li>SCAMP Tool filters SP policy to only accept users and user information from specific collaborators </li></ul>SP etc… IdPs S C A M P
  19. 19. SPAM-GP – SCAMP Attribute Select
  20. 20. SPAM-GP – SCAMP Site Select
  21. 21. SPAM-GP – CCP Motivation <ul><li>Unlinked infrastructures: </li></ul><ul><ul><li>Log into IdP, then log into Portal with separate credentials </li></ul></ul>IdP SP
  22. 22. SPAM-GP – CCP <ul><li>CCP Linked infrastructures: </li></ul><ul><ul><li>Log into IdP, then THIS information is used to automatically log in to the portal </li></ul></ul>IdP SP
  23. 23. SPAM-GP - ACP <ul><li>Generates, signs and publishes X.509 Attribute Certificates for access to external PERMIS-protected web services </li></ul><ul><ul><li>Utilising roles filtered by SCAMP and saved to GridSphere role database </li></ul></ul><ul><ul><li>Have provided instructions for LDAP server setup </li></ul></ul>
  24. 24. Shintau <ul><li>Allows linking of IdPs when logging in </li></ul><ul><ul><li>User logs in at home institution as usual, but external IdPs may be linked using Shintau Linking Service (LS) to build up more attributes than the home institution asserts </li></ul></ul>EDINA IdP? LS IdP
  25. 25. Challenges and Questions <ul><li>Will we ever be able to rely on IT inexperienced users to handle digital certificates? </li></ul><ul><ul><li>I suspect not, so automation essential </li></ul></ul><ul><ul><ul><li>Should CA handle all certificates and expose them like a Shibboleth IdP? </li></ul></ul></ul><ul><ul><li>Do we need digital certs at all? </li></ul></ul><ul><li>Where is the best place to store role information for users? </li></ul><ul><ul><li>Should ACs be retained by the resource provider, or disemminated directly to users? </li></ul></ul><ul><ul><ul><li>The former involves less info flow, but the latter requires less manpower. </li></ul></ul></ul><ul><li>Are the end users the best people to assert privilege? </li></ul><ul><ul><li>Automation is desirable, but very difficult </li></ul></ul><ul><ul><ul><li>If the user knows which resource they want to access, should THEY select the appropriate credentials? </li></ul></ul></ul>