Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

  • Be the first to comment


  1. 1. Single Sign On (SSO) By Laxman Kumar
  2. 2. Agenda • Authentication / Authorization • Single Sign On • Why SSO • Protocols • SAML • Meta-data • Working principle • SSO providers • Demo
  3. 3. Authentication / authorization • Authentication Authentication verifies who you are. Two question arises. Example Who is the user lucky? Is the user lucky really who he represent himself to be?
  4. 4. Authentication / authorization • Authentication How can you authenticate ? Knowledge - Something You Know – password, four-digit pin number Possession - Something You Have - smart card, one-time SMS code Inherence - Something You Are - prove who you are using biometrics - fingerprint, voiceprint, or other unique physical feature. Multifactor authentication - e.g: Multi-Factor Authentication at the ATM, OTP
  5. 5. Authentication / authorization • Authorization Authorization verifies what you are authorized to do. Many questions arises. Is user lucky authorized to access resource called ABC ? Is user lucky authorized to perform operation XYZ ? Is user lucky authorized to perform operation P on resource R ? Is user lucky authorized to download or upload files ?
  6. 6. Single Sign On • Single sign-on (SSO) is a technique of access control of multiple related, but independent software systems. • Single sign-on (SSO) allows a person to authenticate once and gains access to all application without being prompted to log in again • Token is used to authenticate the user. • Token is issued to user on successful authentication which is stored in browser (cookie) and can be presented to websites as evidence of authentication.
  7. 7. Single Sign On Previous Technology SSO
  8. 8. Why SSO • User Perspective PROBLEM Too many credentials Multiple login Remembering too many password
  9. 9. Why SSO • IT Perspective PROBLEM Provisioning new accounts Password management Auditing user activity De-provisioning users Managing non-employee access
  10. 10. Why SSO • Eliminate the need for multiple usernames and passwords. • Allow users to manage a single set of corporate credentials. • Give users one-click access to all their applications from anywhere on any device. • Reduce IT help desk cost.
  11. 11. Protocols • SAML- Currently the most widely adopted standard for Web SSO. XML based. • OpenID Connect - Most promising successor to SAML. • Oauth- OAuth is an open standard for authorization. • Earlier protocols that are still in use should be deprecated: Kerberos, RADIUS, LDAP, OpenID 2, CAS...
  12. 12. Oauth • OAuth is an open standard for authorization. • OAuth 1.0 in 2010, OAuth 2.0 in 2012 • Authorize third-party access to their server resources without sharing their credentials • Works with HTTP. • OAUTH 2.0
  13. 13. OPENID • Open standard released in 2006 • Decentralised Single Sign-on for web • For consumer apps and services • Social networks • OpenID 2.0 used XML and a custom message signature scheme.
  14. 14. SAML • Security Assertion Markup Language (SAML). • OASIS open standard for representing and exchanging user identity, authentication, and attribute information. • XML based protocol. • Flexible to work with other protocols. • SAML 2.0
  15. 15. Anatomy of SAML • Assertions • Protocols • Bindings • Profiles
  16. 16. SAML 2.0 SAML Assertion • XML-formatted security token. • Used to transfer user identity and attribute information from the identity provider to a trusted service provider as part of the completion of a single sign-on request. SAML Assertion basically contains •<saml:Issuer> element ,contains the unique identifier of the identity provider •<ds:Signature> element, contains an integrity-preserving digital signature. •<saml:Subject> element, contains authenticated user information. •<saml:Conditions> element, contains conditions under which the assertion is to be considered valid •<saml:AuthnStatement> element, which describes the act of authentication • at the identity provider In words, the assertion encodes the following information: The assertion ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") was issued at time "2004-12- 05T09:22:05Z" by identity provider ( regarding subject (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) exclusively for service provider ( The authentication statement, in particular, asserts the following: The principal identified in the <saml:Subject> element was authenticated at time "2004-12- 05T09:22:00" by means of a password sent over a protected channel.
  17. 17. SAML 2.0 • Protocols – Describes how SAML elements are packaged within SAML request and response element. • Bindings - Mapping of a SAML protocol message onto standard messaging formats and/or communications protocol (Redirect , POST, SOAP Binding) • Profiles - Describes in detail how SAML assertions, protocols, and bindings combine to support a defined use case.
  18. 18. Meta-Data • Metadata is data that describes other data. • Metadata summarizes basic information about data. • It provides information about a certain item's content. • For example, an image may include metadata that describes how large the picture is, the color depth, the image resolution, when the image was created, and other data.
  19. 19. Meta-Data SAML 2.0 Metadata Question 1 How does the identity provider know the service provider is authentic and not some evil service provider trying to phish private information regarding the user? Answer The identity provider consults its list of trusted service providers in metadata before issuing an authentication response. Question 2. How does the identity provider know where to redirect the user with the authentication response? Answer The identity provider looks up a pre-arranged endpoint location of the service provider in metadata. Question 3 How does the service provider know that the authentication response came from a trusted identity provider? Answer The service provider validates the signature on the assertion using the public key of the identity provider from metadata. Metadata ensures a secure transaction between an identity provider and a service provider
  20. 20. Working principle Single Sign on include 3 parties. • User: Requests a service from the service provider. • Service Provider(SP): It servers the authenticated user request. For authentication it checks the ticket provided by SSO server. It also makes an access control decision. • Identity Provider(IDP) or SSO server: It authenticates the user and provide them the ticket.
  21. 21. Working principle
  22. 22. Working principle User Service Provider (SP) Identity Provider (IDP)/ SSO server User request for service to service provider Service Provider checks if user have any ticket. If user doesn’t have then service provider send user to IDP for authentication. Redirect user to Identity provider login page. User Redirected to SSO login page. IDP check user credentials and if correct then issue ticket to user User login with the login credentials And redirect user to service provider with ticket User is redirected to service provider with a copy of ticket SP checks the ticket and if it is a valid ticket SP allows the user to get in. Now SP checks whether the user is allowed to access the service requested for. Service request
  23. 23. Working principle User Service Provider (SP) Identity Provider (IDP)/ SSO server User is request for another service with a copy of ticket SP check the ticket validity and allows the user to get in if ticket is valid
  24. 24. SSO Providers
  25. 25. SSO PROVIDERS Provider Name Product Name Microsoft Active Directory Federation Services, Forefront Identity Manager IBM IBM Enterprise Identity Mapping, LTPA, IBM Tivoli Access Manager Red Hat FreeIPA, JBoss SSO, Keycloak Forge Rock OpenAM VMware myOneLogin Jasig CAS OneLogin Inc. One Login Ping Identity Ping Dock SSOCircle Public SSOCircle, IDPee
  26. 26. DEMO • SAML SSOCircle