Experiences in federated access control for UK e-Science
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Experiences in federated access control for UK e-Science



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

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



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Experiences in federated access control for UK e-Science Presentation Transcript

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