The Shibboleth Service provides middleware for the authentication of Oxford users and the release of a defined attribute set, via an Identity Provider (IdP) to trusted Shibboleth Service Providers (SP). Shibboleth facilitates federated access management where the user's home institution authenticates the user and the Service Provider decides, on the basis of attributes received from the home institution, what authorisation, if any, the user has to access a networked resource. The implementation of Shibboleth at Oxford interoperates with Web-based Single Sign On (Webauth) to enable authenticated access to trusted networked systems (whether the user is within or outwith Oxford). The Shibboleth IdP service can be used to support access to systems within Oxford where a Shibboleth Service Provider is considered more appropriate than the direct implementation of Webauth, including access to an Oxford system by remote users using their home institution's IdP. Examples of services where the end-user will encounter Shibboleth include:
- access to external digital resources licensed by Bodleian Libraries (via OxLIP+)
- access to the Oracle Student System (OSS)
- access to the CareerConnect service managed by the Careers Service
- Provision of infrastructure for web-based, federated SSO authentication of Oxford SSO account holders to registered ITSS within Oxford University.
- Registered ITSS wishing to use this service may contact email@example.com for advice on implementing the Shibboleth Service Provider (SP) modules or to register a trusted, remote Service Provider within the Shibboleth Attribute Release Policy.
- 9am - 5pm on weekdays: the service operates with full technical support.
- All other times: the service operates without technical support. Automated service monitoring will take place, and informal arrangements exist for staff to be notified of exceptions, however no funding is provided for contractual cover or guaranteed response.
- Exclusions: service maintenance carried out during the JANET maintenance period (7am - 9am every Tuesday).
2.7 Software updates are applied by OUCS staff – this is done with the minimum of interruption to service. Any scheduled downtime for maintenance or upgrade will be notified at least 24 hours in advance.
2.8 OUCS is responsible for managing Oxford University's membership of the UK Access Management Federation, including ensuring compliance with the Federation's Rules of Membership.
- eduPersonScopedAffiliation (by default, firstname.lastname@example.org);
- eduPersonTargetedID (an opaque, pseudonymous but persistent identifier that allows for personalisation services by a service provider without that service provider requiring any personal details);
- eduPersonPrincipalName (for those Service Providers that require it, in the form email@example.com)
- eduPersonEntitlement (assertion that user satisfies additional criteria to enable authorisation by Service Provider)
2.10 Notification of faults, outages, etc is circulated on the mailing list firstname.lastname@example.org.
2.11 Technical support (operations and 2nd/3rd line user support) for the service is provided by OUCS. Service requests and fault reports relating to the service should be sent to the OUCS Help Centre.
2.12 User support (1st line) for the service is provided through a combination of local IT support (via local ITSS) and the OUCS Help Centre. Users should seek support from their local ITSS in the first instance. Local ITSS may refer a user to OUCS, or contact OUCS on behalf of a user. Users and ITSS may always contact OUCS about any aspect of the service. The initial point of contact for user support at OUCS is the Help Centre - in person, by telephone, or using our contact form.
3.1 Departments and colleges deploying a Shibboleth Service Provider interoperating with the central Shibboleth Identity Provider must comply with any applicable terms of usage, whether of OUCS or the UK Federation.
3.2 End-users are responsible for maintaining the security of their Single Sign-on password, and in particular for ensuring that authenticated sessions are not left in operation unattended or after the user has finished using them.