1. Joint Information Systems Committee 01/04/2014 | | Slide 1 Single Sign-On Solutions Nicole Harris Programme Manager – JISC

2. Joint Information Systems Committee 01/04/2014 | slide 2 Thanks To Brian Gilmore, who provided much of the material for these slides! JISC report can be found at: –http://www.jisc.ac.uk/uploaded_documents/CMSS-Gilmore.pdf.http://www.jisc.ac.uk/uploaded_documents/CMSS-Gilmore.pdf Disclaimer: speaker has no direct experience of implementing SSO solutions! Questions via the WIKI please: –federation.pbwiki.com –Login: shibboleth

3. Joint Information Systems Committee 01/04/2014 | slide 3 Roadmap for Institutions

4. Joint Information Systems Committee 01/04/2014 | slide 4 The Problem PC Login School Web Site - Login College Intranet -Login Staffmail -Login Corporate Services - Login ATHENS -Login WIZARDeFinancials Other External Services -Login ESP -Login WebCT/ EEMEC -Login E-Diary -Login etc

5. Joint Information Systems Committee 01/04/2014 | slide 5 What is Single Sign-On? Used to refer to many different approaches, such as: –LDAP look-up; –Shared name / password; –One sign-on, one database.

6. Joint Information Systems Committee 01/04/2014 | slide 6 Approaches to Single Sign-On LDAP Look-Up: –A number of sites claim they have single sign-on by having a single LDAP database which a number of services access. –Not true SSO as the user is challenged individually by each service. Shared Name / Password: –Multiple, separate name/pass stores, possibly with synchronisation; –User experience may be the same as true SSO; –But, higher risk, different security levels, compromise one equals compromise on all, possibility of unencrypted passwords in system and/or across the network. True Single Sign-On: –There is a single, well protected, store of user names & passwords –Interrogated by multiple services –User enters (particular) credentials once, and only once –Consistent, overall timeout can be applied – how long is an issue!

7. Joint Information Systems Committee 01/04/2014 | slide 7 Do We Want SSO? If a user is compromised then all the resources open to that user are compromised. Important to consider a Risk Analysis to determine the balance between usability and security.

8. Joint Information Systems Committee 01/04/2014 | slide 8 Potential Sign-On Model Sign-on at 3 distinct levels: –External Network Logon –Normal Internal level –High Risk Areas Can be other models! Federated Access Management concentrates on web-based resources, although successful trials with network level access.

9. Joint Information Systems Committee 01/04/2014 | slide 9 Pre-requisites for SSO You have to know who *all* your users are. SSO implies automation, therefore special cases are a problem: –Students –Staff –Alumni –Others Others problem area: –Casual staff visitor to a department –External Uni PhD students working in your institution –Medical staff who teach –Retired staff casually still working in a department Refers to stage two in the JISC Roadmap document!

10. Joint Information Systems Committee 01/04/2014 | slide 10 JISC Web-Based SSO Study - 2004 Note that carried out in 2004 – looking to update. Systems evaluated: –CAS (Yale) –Pubcookie (Washington) –WebAuth (Stanford) –Cosign (Michigan) –KX.509 (Michigan) Systems not fully evaluated: –A-Select (not fully) –Shibboleth as an SSO (not at all)

11. Joint Information Systems Committee 01/04/2014 | slide 11 Overview of Results UsageSingle Pt Failure SupportDocum- entation Availability of authentication modules Shibboleth enabled CASModerateYesPoor V poorNo at time. Yes now! PubcookieWidely used YesVariableSmall amount VariableYes now! WebauthNot Widely used NoResponsiveV goodPoorNo CosignRelatively new NoV Responsive smallGoodHas been demonstrat ed A-SelectModerate inside NL YesResponsive, commerciall y available GoodV GoodYes

12. Joint Information Systems Committee 01/04/2014 | slide 12 JISC Project Experience CAS: LSIP at Liverpool –http://www.liv.ac.uk/LSIP/Documentation/ImplementationofYaleCASSSO.htmlhttp://www.liv.ac.uk/LSIP/Documentation/ImplementationofYaleCASSSO.html Pubcookie: IAMSECT at Newcastle –http://iamsect.ncl.ac.uk/deliverables/docs/shib_install/http://iamsect.ncl.ac.uk/deliverables/docs/shib_install/ Webauth: SPIE at Oxford –http://spie.oucs.ox.ac.uk/Wiki.jsp?page=Outputshttp://spie.oucs.ox.ac.uk/Wiki.jsp?page=Outputs Cosign: AMIE at Edinburgh –www.ucs.ed.ac.uk/projects/amiewww.ucs.ed.ac.uk/projects/amie A-Select: –No existing UK experience (to the knowledge of JISC and Google)

13. Joint Information Systems Committee 01/04/2014 | slide 13 Edinburgh in Focus Decided to implement Cosign –Strong links with kerberos (strong linux presence) –Liked the support –No single-point of failure –But no IIS support (yet) 29 services now covered by SSO 23 services not covered 6 of them soon! Individual machines Departmental services Commercial Packages Takes time and significant buy-in from depts etc

14. Joint Information Systems Committee 01/04/2014 | slide 14 Reflections from Edinburgh Implementing a SSO system is loved by the users Which system, original SSO or Shibboleth will depend upon your circumstances You really do need to know who all your users are!