i2Q & WMnet Pilot

Presented by Jason Rousell – i2QJay Neale - i2Q

“To investigate the suitability of Shibboleth for the UK Schools and Content Provider sectors”

Pilot: The questions we asked….

1. What does an RBC, LEA or School have to do to become an Shibboleth Identity Provider?

2. What does Shibboleth mean for the different types of Content Provider?

3. What supporting structures will be required to make Shibboleth work in the UK?

General Findings: Identity ProvidersIntegration with existing systems required (middleware):

Shibboleth has to fit into existing RBC/LEA information architecture (Portals etc.) Existing authentication systems hooked into IdP software (Bespoke / PubCookie etc.)

User data availability

User data widely available – requires some standardisation Various methods for populating authentication / attribute store (distributed LDAP etc.)

User attributes availability / requirements

Various data sources available to populate user attribute store (existing DBs, EMS, MIS) Decision on Attribute Store architecture (LDAP / DB) and schema (eduPerson / UK variant) Only limited number attributes required for many existing subscription services More specific attributes required for individualised/differentiated services can be provided

Configuration issues

System integration (WebISO / IdP) Extending basic attribute retrieval (JNDI Connectors) Enabling group/user level attribute release

Advantages Standards compliant

Simplify digital content/services access

Greater user flexibility – multiple federation membership / privacy controls

Opportunity to rationalise user data management systems

Increase user data security

Protect user’s privacy

Better interoperability with other RBCs/LEAs

General Findings: Identity Providers

Disadvantages

Pre-requisites (webISO)

Setup issues

General Findings: Service ProvidersIntegration with existing systems required

SP’s already have existing authentication systems, some of which feed into backend business systems (i.e. audit tracking / subscription)

Possible to integrate Shibboleth front-end to pass user credentials to existing systems

Managing User Access to Resources

Simplest access control possible without any additional development (i.e. only allow authenticated users from these IDPs to access resource in AAP.xml)

Advanced resource protection may require additional development (i.e. authorisation handler to intercept and process requests based on attributes received)

Should be possible to map existing user credentials to received attributes, but consensus required on what attributes will be available to SPs (i.e. Federation guidelines)

Configuration Issues

Standard setup on Windows (ISAPI filter) and Linux (Apache Handler) straightforward Existing SSLs can be used

Service Provider: Scenarios

School user requests Shibboleth protected contentfrom provider

Content Provider’s Shibboleth software intercepts and checks if user has authenticated locally

If successful user’s attributes returned to SP for next stage - authorisation

SP is configured to only allow access to authenticated users from school A – access to the resource is granted

This level of protection can be achieved with minimal configuration of SP’s AAP.xml (acceptable attribute policy)

Service Provider: Scenarios

School user requests Shibboleth protected content from provider

Content Provider’s Shibboleth software intercepts and checks if user has authenticated locally

SP is configured to pass received attributes to authorisation handler

The handler extracts eduPersonPrimaryAffiliation and ukSchEduPersonDOB to determine the user is a KS3 pupil from School A

The handler then redirects the user to the relevant resource area

This level of protection requires some additional development

Service Provider: Scenarios

First time user accesses (post Shibboleth) still prompted for username and password

Details checked against existing authentication. If successful process continues by retrieving user’s Shibboleth credentials

Once retrieved user’s Shibboleth ID (i.e. uid) is stored in the existing authentication system, so that on subsequent requests it can be used for authorisation

The handler then redirects the user to the relevant resource area

This level of protection requires additional development

Advantages

Standards compliant

Reduced user data management

Simple ‘subscription enabling’ process

Flexible resource protection

Protect multiple resources easily

Wider route to market

Stepped migration path possible

Easier interoperability with new markets (overseas? Etc.)

General Findings: Service Providers

Disadvantages

Setup and configuration

Possible backend system integration

Cost (consultancy etc.)

General Findings: Wider ContextStandards

Shibboleth gaining wide acceptance in UK HE and internationally

eduPerson provides basic attribute requirements, benefits from wide endorsement (UK variant of eduPerson investigated based on CBDS)

SSL certificates and Metadata integral part of Shibboleth trust fabric – clear guidance required on metadata requirements and which SSL authorities supported

1.3 metadata significantly different to 1.2 – not a long term option to support 1.2

Central Services

Federation necessary for any level of interoperability

SSL issuing etc. presents sizable management overhead

Automating membership process, metadata creation and dissemination necessary

Federation also a gateway – therefore, set of information / support services for potential members required

Pilot: Conclusions

Widespread adoption in US and UK HE sectors

Number of major US providers now providing Shibboleth access

Adoption of standards key to success (Shibboleth 1.3, eduPerson, CBDS)

Period of migration inevitable

Support structures (Federation, help lines etc.) required

Potentially lead to better system integration – i.e. where SPs could securely utilise MIS data without manual overhead

Inter RBC/LEA Shibboleth authentication likely to increase

Future developments: School based IdP integrated with Active Directory