Experiences in Federated Access Control for UK e-Science John Watt
EduServe Symposium 2009 , London
May 21st 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 1Person 2…….etc……Person 32637Person 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
University Registry
IdP
• Each member of the University has a unique identifier (GUID)• User logging in with this GUID successfully is authentic University member
GUID+password
GUID query
Authenticated
GLASS – Authentication and Authorisation
University Registry
IdP
• Departments push user roles/attributes (green) to Registry database• Roles/attributes can be asserted by the Identity Provider on behalf of each
department
GUID+password
GUID query
Authenticated + Attributes
Physics
Engineering
Attributes
GLASS – Authentication and Authorisation
University Registry
IdP
• 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
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)
GLSEDINAAttributeAuthority
EDINA-SignedRole 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
EDINAAttributeAuthority User
Check
SimilarManchester
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
SCAMP
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
EDINAIdP?
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?