SSO Basics

Single Sign-On, What is it?

Single Sign-On is a method of authentication that allows for the consolidation of identities across multiple applications within a company/domain. Single Sign-On streamlines logins by having a singular login provider - also known as the Identity Provider (IdP) work with multiple applications/ Software as a Service companies (SaaS), also known as a Service Providers (SPs).

SSO is typically accomplished via Security Assertion Markup Language (SAML), which provides several authentication and session migration steps to bring users to their authorized applications seamlessly.

SAML accomplishes this in several steps (Example of a real-life equivalent in parentheses):

1. A user that is part of a domain requests access to a service. (Imagine entering a business that requires a state license of some kind, perhaps purchasing reactive chemicals. The State is the IdP, the business is the SP, you are the user requesting access)

2. The service provider carries the user’s information to the identity provider, to initiate authentication. This is called the SAML Request. It is the service provider requesting user information about an account within a specific domain (within the IdP), under the premise that the user should be granted access if they can authenticate that they are the genuine user. (Think about it like the business scanning your State license and looking it up on a state website to see that you are a valid license holder)

   • If the user’s account does not exist within the IdP, the session is rejected and the user is bounced back the SP page with an error message. (You don’t have a license, what you brought was your state ID and that doesn’t work for buying something like dangerous chemicals)

3. The user then authenticates at the Identity Provider’s authentication page. The result of this authentication is then sent to the service provider as a response. The authentication response is typically either called the SAML Response or SAML Assertion. The reason it is an assertion, is due to the fact that the IdP is asserting that an account exists with an SP, for a given user, with specific attributes that dictate their access. This assertion can lead to various results:

   • If the user was successfully authenticated, it sends the user’s attributes back to match them to a service provider held account.

     • If the user doesn’t have an account that matches their attributes on the Service Provider’s application, the service provider’s Assertion Consumer Service (ACS) rejects the session and typically provides the user with an error message. (Your state license is valid, but you have no account with the business you are trying to buy from. You could theoretically buy the chemicals, but you would first need to get set up with a business account for the chemical distributor before you could start a purchase)

     • If the user’s primary attributes match, they are relayed to the service. (Your license was valid, you can buy chemicals from the distributor/business)

   • If the user authenticates successfully, but does not have permission to access the application, it rejects the user’s authentication attempt and the user is relayed a failure message from the identity provider’s website/auth service. (Your license is valid, but not for purchasing these kinds of chemicals. They cannot sell to you.)

   • The user does not authenticate successfully, and the session is rejected. (Your license was fraudulent or expired, you cannot buy the chemicals.)

4. A valid authenticated response (SAML Assertion/Response) is ingested, and the service provider provides access to the content. (You can buy chemicals at the business)

Single Sign On can be either Service Provider initiated or Identity Provider initiated. In SP-initiated SSO, the SAML request must come from the service provider. In IdP-initiated SSO, from the IdP. This leads to some security concerns for IdP-initiated login:

• Where does the request come from?

  • The request is user-initiated at the IdP-side, so there is no authority other than a user session ensuring the request is sent out. This is not an issue, unless the IdP itself is unsecure, which would defeat the purpose of SAML

• How is the request validated?

  • The IdP assertion and response are combined into a single SAML assertion, which automatically initiated the SP session once received by the SP’s Assertion Consumer Service (ACS). The user is automatically passed the session at the SP, allowing for instantaneous login.

• What are the risks with IdP-initiated SSO then?

  • Since the token must travel through from the IdP to the SP, a MitM attack could potentially intercept the token and hijack the user session, without any knowledge from the user. This could be performed through a network traffic interception tool or other common MitM techniques for internet traffic.

  • SAML 2.0 uses an InResponseTo property for SAML assertions, which enforces that a single SAML response is valid for a single request, but this only stops repeat usage of assertion tokens, not intercepted tokens.

  • Another method to use to mitigate this issue could be cached memory of valid user sessions, to check against, and block invalid sessions. This would only work for users that successfully authenticated at least one time.

Due to the nature of this issue, I do not recommend implementing IdP-initiated SSO, unless no other authentication options are available or viable.