• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Experiences in federated access control for UK e-Science
 

Experiences in federated access control for UK e-Science

on

  • 1,121 views

A presentation by John Watt given at the Eduserv Symposium 2009 in London during May 2009.

A presentation by John Watt given at the Eduserv Symposium 2009 in London during May 2009.

Statistics

Views

Total Views
1,121
Views on SlideShare
1,116
Embed Views
5

Actions

Likes
0
Downloads
3
Comments
0

1 Embed 5

http://www.eduserv.org.uk 5

Accessibility

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.

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

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

    • Experiences in Federated Access Control for UK e-Science John Watt EduServe Symposium 2009 , London May 21 st 2009
    • Overview
      • Some basic concepts
      • NeSC Projects
        • GLASS
        • SEE-GEO
        • SPAM-GP
        • Shintau
      • Challenges and Questions
    • Interfacing Technologies Authentication: Who are you? Authorisation: What can you do? VOMS INDIVIDUAL ORGANISATION ?
    • 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……
    • 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
    • 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
      • EDINA_SEEGEO_RA
      • etc…..
    • 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
    • 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
    • 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
    • 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
    • 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
    • SEE-GEO – Portal-based Static Security
      • Geolinking Service (GLS) Portal with in-portal centralised user management
      GLS
    • SEE-GEO – Current Shibboleth-based security
      • Separate Shibboleth-protected (dashed line) web pages
      • Extraction and staging is a manual process (No auto GLS)
    • 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
    • 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
    • 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
    • SPAM-GP - SCAMP
      • Registration of a Service Provider with UKAMF builds trust relationship with ALL Federation Identity Providers
      SP etc… IdPs Register
    • 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
    • SPAM-GP – SCAMP Attribute Select
    • SPAM-GP – SCAMP Site Select
    • SPAM-GP – CCP Motivation
      • Unlinked infrastructures:
        • Log into IdP, then log into Portal with separate credentials
      IdP SP
    • SPAM-GP – CCP
      • CCP Linked infrastructures:
        • Log into IdP, then THIS information is used to automatically log in to the portal
      IdP SP
    • 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
    • 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
      EDINA IdP? LS IdP
    • 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?