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

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…

Gridcoin - The Good

In this post we will take an in depth look at the cryptocurrency Gridcoin, we show how we found two critical design vulnerabilities and how we fixed them. In the last past years we saw many scientific publications about cryptocurrencies. Some focused on theoretical parts [Source] and some on practical attacks against specific well-known cryptocurrencies, like Bitcoin [Source]. But in general there is a lack of practical research against alternative coins. Or did you know that there are currently over 830 currencies listed online? So we asked ourselves how secure are these currencies, and if they are not just re-branded forks of the Bitcoin source code? Background Gridcoin is an Altcoin, which is in active development since 2013. It claims to provide a high sustainability, as it has very low energy requirements in comparison to Bitcoin. It rewards users for contributing computation power to scientific projects, published on the BOINC project platform. Although Gridcoin is…

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