1 / 28

Single Sign-On

Single Sign-On. Brian Gilmore Computing Services, University of Edinburgh. Why is it a problem ?. Shouldn’t need to tell this audience! But, how many logins do you have?. Corporate Services - Login. Other External Services -Login. ATHENS -Login. WIZARD. eFinancials. etc.

bartram
Télécharger la présentation

Single Sign-On

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related