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

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers. The issue: CORS misconfiguration Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misc…

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…