Direkt zum Hauptbereich

Single Sign-On

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.
During the Authentication flow the user will be authenticated on the IdP and afterwards on the SP.
  • 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.


The Security Assertion Markup Languange (SAML) is one of the most used standards for Identity Management. SAML is based on the eXtensible Markup Language (XML) and enables the secure exchange of XML-based authentication and authorization messages. In conjunction with SSO systems, SAML especially offers a standardized format for authentication tokens.

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
The parameters that are usually contained in the Token Request are:
  • 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

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.
Please note, that all these values are not protected by the signature. Thus, they can be easily manipulated.

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.
  • Information about the issuer (the IdP). The value is usually identical with the Issuer in the Response.
  • Information about the authenticated subject, e.g. the user. Usually the identity of the user is stored in: 
Additional user information can be provided in the 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:
  • The digital signature can contain information about:
    • The used algorithms
    • The signed elements.
In this case the URI-attribute in the Reference-element points to the Assertion with ID "_a30d534...da5d".
    • The signature value
    • The used key

Digital Signature contained in the SAML Token

Authors of this Post

Vladislav Mladenov
Christian Mainka (@CheariX)
Florian Feldmann

Beliebte Posts aus diesem Blog

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

DTD Cheat Sheet

When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

In this post we provide a comprehensive list of different DTD attacks.

The attacks are categorized as follows:
Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT

Practical Dictionary Attack on IPsec IKE

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.