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?