Single Sign-On

1. Single Sign-On Brian Gilmore Computing Services, University of Edinburgh EuroCAMP April 2006

2. Why is it a problem ? • Shouldn’t need to tell this audience! • But, how many logins do you have? EuroCAMP April 2006

3. Corporate Services - Login Other External Services -Login ATHENS -Login WIZARD eFinancials etc Staffmail -Login ESP -Login WebCT/ EEMEC -Login E-Diary -Login PC Login School Web Site - Login • College Intranet • Login EuroCAMP April 2006

4. What is Single Sign-On (SSO) ? • LDAP Look-up • Shared name/password • One sign-on, One database EuroCAMP April 2006

5. 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 EuroCAMP April 2006

6. 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 EuroCAMP April 2006

7. 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! EuroCAMP April 2006

8. Do we really want true 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 useability and security EuroCAMP April 2006

9. Possible model • 3 distinct levels • External Network Logon • ‘Normal’ Internal level • ‘High Risk’ Areas • Can be other models! EuroCAMP April 2006

10. External Network Logon • This is probably the most vulnerable link • Users of shared machines • Sniffability of wireless networks • If the 1st level is broken, the 2nd level will probably still be ok • BUT.. Don’t forget keyboard sniffers! EuroCAMP April 2006

11. Normal Internal Login • Level used for all ‘normal’ risk applications (and people) • Vulnerable to internal frauds etc • But more secure to external threats EuroCAMP April 2006

12. High Risk Areas • Examples: People able to: • sign 1m euro cheque • Add persons to the payroll • Achieve ‘root’ or administrator privilege • Also, consider an additional ‘check’ for anyone to change their address etc • Use of one-time passwords possible (cost!) EuroCAMP April 2006

13. What are the pre-requisites ? • You have to know who *all* your users are • SSO implies automation, therefore ‘special cases’ are a problem • Students • Staff • Alumni • ‘Others’ EuroCAMP April 2006

14. Others • This tends to be the 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 EuroCAMP April 2006

15. Back to definition of SSO • Two disparate types of system • Web Based Systems • Others • Actually a third: • Commercial systems with no API EuroCAMP April 2006

16. Non Web-based Systems • More of them than at first sight • Library systems • Not for catalogue lookup, more • Fine handling • Situations where user behaviour is remembered • Some portal systems • Where they wish to handle Authentication by themselves and do proxy (pass on) actions • Network Login/Unix systems • Requires removal of login mechanism EuroCAMP April 2006

17. Web-based SSO Systems • Edinburgh had a JISC project to investigate web based SSO systems • Performed in 2004, so is now out of date but gives a flavour • Is stored at: http://www.jisc.ac.uk/index.cfm?name=prog_middss_studies Or enter into google: JISC Single Sign-on Technologies EuroCAMP April 2006

18. Systems Evaluated • CAS (Yale) • Pubcookie (Washington) • WebAuth (Stanford) • Cosign (Michigan) • KX.509 (Michigan) EuroCAMP April 2006

19. Systems not fully evaluated • A-Select • Shibboleth EuroCAMP April 2006

20. Results • All solutions are cookie based, except for KX.509 • There are issues with cookies • Single Point of Failure • How well is it architected to avoid SPF? • Support/Documentation/Usage • Quality (when we looked!) EuroCAMP April 2006

21. Feature Table (2004!) EuroCAMP April 2006

22. In Edinburgh • Decided to implement Cosign • Strong links with kerberos (strong linux presence) • Liked the support • No single-point of failure • But no IIS support (yet) EuroCAMP April 2006

23. Edinburgh • 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 EuroCAMP April 2006

24. Shibboleth • Shib can (and is) used as a campus SSO • Advantage: • same system inside as outside • Fine grained Authorisation possible • Version 2 will make this easier, will do authentication rather than relying on something like Apache EuroCAMP April 2006

25. Shibboleth • Disadvantages: • Considerably more complex to install on every web system • Would appear to be a number of single points of failure difficult to overcome. SSO expected to be 24x7x365 EuroCAMP April 2006

26. Shibboleth • Other Issues • New system requires an entry in Federation (national) meta-data, or a local federation • Requires a certificate (but getting easier) • WAYF issues (local & federation?) EuroCAMP April 2006

27. Shibboleth and SSOs • Once an institution has implemented even a partial SSO then implementing Shibboleth is mush easier • You know who your users are! • You have the mechanisms for automating user handling • How many web servers have external, authN users ? EuroCAMP April 2006

28. Summary • 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! EuroCAMP April 2006