1. Lecture 10 Single Sign-On systems

2. What is Single Sign-on? Lets users authenticate themselves once and access different applications without re-authentication Increases the usability of the network Centralizes the management of relevant system parameters Two main type of SSO Systems: Pseudo-SSO and True- SSO

3. Pseudo-SSO

4. True SSO

5. Generic SSO System

6. Categories of SSO Systems SSO architectures can be further categorized based on the location of the Authentication Service Provider ASP/pseudo-SSO component It can be local to the user platform or offered as a service by an external entity (SSO proxy) Four Main Categories of SSO Systems –Local Pseudo-SSO –Proxy-Based Pseudo-SSO –Local True SSO –Proxy-Based True SSO

7. Examples of True SSO

8. SSO Entities Service Providers Need to verify the AS using an Integrity Challenge/Response session which also provides user identification Must have a well-known, human-readable unique identifier (e.g. URI) for users to authenticate SPs before releasing Integrity Response

9. Is SSO the Saint Graal? Apparently not!

10. SSO – 8 Unsolved Problems SSO demands Federated-Trust –Multi-dimensional problem of administration domains SSO Amplifies staff changes and escalates Roles –Client changes become server overheads SSO leads to Information Mismanagement –Servers learn about client organization SSO is Unresponsive to Organization Needs –Delegation consistency is hard to arrange or Revoke SSO Governance leads to loss of Policy Control –ID and Password abuse and data inconsistency SSO increases Ambient Authority risks –All of a ‘principals’ domain authorities are exposed to attack SSO Distributed Management limits scale –Unsynchronized updates lead to service failures SSO System Improvements are resisted –Complexity lock down Federated evolution

11. SSO - The Simple Case One on One –Clients must first provide Services –With the URL for the Client’s SSO service –Client’s public key for service to verify SAML responses

12. SSO - The Realistic Case Domains have their own rules –For principles To Sign On To Transfer to eBay To Check PayPal –Access Policy issues Face Book based on Originator How about eBay and PayPal? –Originator or what? –What about Your Bank? Trust is doubtful! The Originator or some 3 rd Party Intermediary Who decides? –Not you! Domain Face Book 1 2 3 4 5 6 7 Corporation 1 2 3 4 5 6 7 1 2 3 4 5 6 7 eBay 1 2 3 4 5 6 7 Pay Pal 1 2 3 4 5 6 7 Branch 1 2 3 4 5 6 7 Bank Account 1 2 3 4 5 6 7 Like You Like…

13. Federated Identity Management Managing Identities is hard –Access Control List synchronization Federating Identities is worse –Every client adds to the cost of service –This negative feedback limits growth How can a domain control access? –Look up policy by identity –Who is the real Identity? –Access is based on the policy –Access Control Lists set to match If Access Policy is defined –Then use a Capability Pattern –Convey policy with the identity –Certify Access rights to a service –Chained to Some Method on an Object Trusted Partner SAML Policy IdentityPolicy

14. Policy Management Options IBAC –Client change are Server problems! Services authorize IDs –ALC set for roles/identities Know all users and rights Update as users change –Many service partners Many more identities Third party mashups –Scalability is THE problem ZBAC –Client Changes are only Client problem! Service sells Access contracts –Capabilities to service As access to a contract –Clients manage them Distribute by roles –A capabilities for a contract Include ways to revoke –Scalability is possible Authorization-Based Access Control for the Services Oriented Architecture Architecture Alan H. Karp, HP Laboratories Palo Alto

15. The essential difference between these two alternative is the architecture and location of Identity Policy Control Is it on the service side or on the client side. Just a small change in thinking makes a big change in results. When ACL Policy is managed by a service it can not scale as a secure application SOA and SAML are going to make things worse Think of capabilities as secure abstractions (paper money to gold) They can be feely exchanged by the population but protected by the system

16. IBAC Example UC 1. Client sends a Signed Contract to corporate! 2. Manager sends a service-request to client. 3. Client approves user to corporate. 4. Corporate sends site-credentials to manager. 5. Manager sends Work-requests to work site. 6. Work site sends credentials to manager. 7. Manager sends service account to work site. 8. Manager sends credentials to corporate. 9. Manager sends staff-request to client. 10. Client approves identity at corporate. 11. Corporate returns credentials to staff. 12. Staff sends Work-request to work site. 13. work site returns work-credentials to staff. 14. Staff loads Work to the work site. 15. Staff loads work-credentials at corporate. 16. Staff sends Work request to service. 17. service requests Work at work site. 18. work site sends Work to the service. 19. service sends Job-result to staff. ~50% Management Overhead

17. Initial Sign-on Process

18. Key Management Uses shared symmetric keys to encrypt messages sent between application servers and the login server Keys are generated and maintained by the “keyserver” application running on the login server Keys are negotiated and distributed using the “keyclient” utility during the setup phase of each application server Keys can be revoked at the login server, but automated expiration and renewal process are not yet provided

19. References http://iamsect.ncl.ac.uk/dissemination/iss/iss-shib-sans-getis.ppt https%3A%2F%2Fwww.owasp.org%2Fimages%2F2%2F26%2FOWASPSanAnt onio_2006_08_SingleSignOn.ppt&ei=vBvvTpbfDMHT4QTZlpWdCQ&usg=AFQjC NFV7y-o315tnzw2KueaP812joxAfQ&cad=rja http://www.esat.kuleuven.be/cosic/seminars/slides/SSO.pdf http://www.slideshare.net/HitachiID/integrating-password-management-with- enterprise-single-signonhttp://www.slideshare.net/HitachiID/integrating-password-management-with- enterprise-single-signon http://www.cse.fau.edu/~security/public/docs/Federated%20identity%20manage ment%20vs.%20federated%20access%20management.ppthttp://www.cse.fau.edu/~security/public/docs/Federated%20identity%20manage ment%20vs.%20federated%20access%20management.ppt http://www.csun.edu/~andrzej/COMP529-S05/presentations/6.ppt http://www.tdwg.org/fileadmin/2007meeting/slides/Suhrbier_Shibboleth_abs187.p pthttp://www.tdwg.org/fileadmin/2007meeting/slides/Suhrbier_Shibboleth_abs187.p pt http://www.metromidrange.org/PastMeetings/downloads/EIM- SSO%20Overview.ppthttp://www.metromidrange.org/PastMeetings/downloads/EIM- SSO%20Overview.ppt http%3A%2F%2Fwww.rsc-ne- scotland.ac.uk%2Fmcshib%2FPresentations%2Fmchsib-apr08- shib2.ppt&ei=eSYDT-C8MKbm4QTCovmUDQ&usg=AFQjCNGmz4TujYs2c- 9LJu0aWq7u-XczAg&cad=rjahttp%3A%2F%2Fwww.rsc-ne- scotland.ac.uk%2Fmcshib%2FPresentations%2Fmchsib-apr08- shib2.ppt&ei=eSYDT-C8MKbm4QTCovmUDQ&usg=AFQjCNGmz4TujYs2c- 9LJu0aWq7u-XczAg&cad=rja http://cnav.gettysburg.edu/portal/portal07/PostConference/technical/SSO3- HalfwayThere.ppthttp://cnav.gettysburg.edu/portal/portal07/PostConference/technical/SSO3- HalfwayThere.ppt http://www.terena.org/activities/eurocamp/march05/slides/day2/introshib.ppt http://www.terena.org/activities/eurocamp/nov05/slides/day2/sso.ppt

20. Keep on dreaming… that you are secure!