Single Sign-On
Using authentication via Single Sign-On (SSO) has
many advantages over simple Username/Password mechanisms. Whereas for
the latter, the user has to remember multiple different
Username/Password combinations, this overhead can be significantly
reduced with SSO. Also, the security of Username/Password relies
solely on the strength of the password provided by the user, but SSO
allows for the adoption of several technical measures to further
enhance the security of the login procedure.
In general, there are three participants in the SSO authentication scheme:
Service Provider (SP): Controls the resources accessed by the User.
User: Is a normal user navigating his User Agent (UA), e.g. a browser, and requesting restricted resources on different SPs
Identity Provider (IdP): Manages the authentication of different users and
generates authentication tokens for the SPs.
Advantages and Disadvantages of SSO
SSO offers many advantages:- Users do not have to remember multiple Username/Password combinations.
- Security policies regarding the authentication, e.g. forcing the user to select a different password every four weeks, can be easily applied. The user only has to change one single password – the password on the IdP.
- Enforcement of further authentication mechanisms, e.g. Two-Factor authentication, can be applied, without having to modify any of the SPs. By this means, the implementation and integration costs of new authentication mechanisms can be reduced significantly.
The disadvantages of SSO are:
- Privacy: The IdP can record the activities of the users and create profiles.
- Availability: The IdP is a Single-Point-Of-Failure component in the SSO scheme. If it is not available the authentication on the SPs and the usage of their services is not possible.
- Security: If the IdP is insecurely implemented and attacks can be successfully started, the security of the entire infrastructure is at risk.
The SSO protocol flow
The protocol flow includes two phases: Trust establishment and Authentication flow.
In the Trust establishment phase the IdP and SP communicate directly with each other via a secure channel. The Trust establishment phase will be executed only once in order to establish a trust relationship between both parties. The following data will be exchanged:
- ID: A unique identifier.
- Cert_SP/IdP: Key material, e.g.. Certificates, which will be used to verify the digital signature(s) in the SSO messages.
- URL_SP/IdP: The endpoints of the SSO interface. All SSO related messages will be sent to this URL.
- Step 1: The user navigates his browser to a SP and requests some resources.
- Step 2: Since the user is not authenticated yet, the SP generates a Token Request.
- Step 3: The user will be forwarded together with the Token Request to the IdP.
- Step 4: The user will be authenticated. The authentication can be done via Username/Password or other authentication mechanisms, e.g. Two-factor authentication. If the user is already authenticated on the IdP, this step will be skipped.
- Step 5: After the successful authentication of the user, the authentication token will be generated.
- Step 6: The token will be sent through the user's browser to the SP. Afterwards, it will be verified.
- Step 7: If the token is valid, the SP grants access to the restricted resources.
SAML
In the following section we will explain the structure of the SAML messages and their role in the SSO authentication scheme.
Token Request
The Token Request is sent by the SP to the IdP in order to trigger the user's authentication. The Token Request usually does not contain any sensitive information and thus is not protected by a signature. |
| SAML Token Request |
- ID: A nonce, which guarantees that the Token Request is freshly generated.
- IssueInstant: A timestamp.
- AssertionConsumerServiceURL: A URL pointing to the SAML interface of the SP, where the IdP sends the authentication token.
- Version: SAML Version.
- Issuer: The identity of the SP.
SAML Token
The SAML Token is generated by the IdP and sent to the SP through the user's browser. The structure of the token as well as the relevant parameters will be discussed in this section. |
| SAML Token |
Response
The Response-element is the root-element of every authentication token. It can be digitally signed. By this means, the entire authentication token will be protected by the digital signature. However, this feature is rarely used.
The Response contains the following parameters:
- ID: A nonce, which guarantees that the Token is freshly generated
- IssueInstant: A timestamp.
- Version: SAML Version.
- InResponseTo: An optional parameter containing the ID of the Token Request received by the IdP. By this means, the SP can assign the received token to the sent request.
- Issuer: The identity of the IdP.
Assertion
The Assertion is the most important part of the token. It contains the following information:
- ID: A nonce, which guarantees that the Token is freshly generated
- Timestamps - Every authentication token contains time limitations according its validity.
/saml2p:Response/saml2:Assertion:IssueInstant
/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmationData:NotOrAfter
/saml2p:Response/saml2:Assertion/saml2:Conditions:NotOrAfter
- Information about the issuer (the IdP). The value is usually identical with the Issuer in the Response.
/saml2p:Response/saml2:Assertion/saml2:Issuer
- Information about the authenticated subject, e.g. the user. Usually the identity of the user is stored in:
/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID.
Additional user information can be provided in the AttributeStatement:
/saml2p:Response/saml2:Assertion/saml2:AttributeStatement.
- Information about the recipient of the token. This is in most cases the URL of the SP. By this means an authentication token is restricted to a specific audience. Parameters providing information about the recipient are:
/saml2p:Response:Destination
/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmationData:Recipient
/saml2p:Response/saml2:Assertion/saml2:Conditions/AudienceRestriction
- The digital signature can contain information about:
- The used algorithms
/saml2p:Response/saml2:Assertion/ds:Signature/ds:SignedInfo
- The signed elements.
/saml2p:Response/saml2:Assertion/ds:Signature/ds:SignedInfo/ds:Reference:URI
In this case the URI-attribute in the Reference-element points to the Assertion with ID "_a30d534...da5d".
- The signature value
/saml2p:Response/saml2:Assertion/ds:Signature/ds:SignatureValue
- The used key
/saml2p:Response/saml2:Assertion/ds:Signature/ds:KeyInfo
 |
| Digital Signature contained in the SAML Token |
Authors of this Post
Vladislav MladenovChristian Mainka (@CheariX)
Florian Feldmann
