1. i2Q & WMnet Pilot Presented by Jason Rousell – i2Q Jay Neale - i2Q

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

3. 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?

4. General Findings: Identity Providers Integration 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

5. 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

6. General Findings: Service Providers Integration 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

7. Service Provider: Scenarios School user requests Shibboleth protected content from 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)

8. 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

9. 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

10. 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.)

11. General Findings: Wider Context Standards 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

12. 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