Lock symbol

Service for employees

Login and authentication service (Single Sign On - SSO)

TIK provides a central identity provider (IDP) that users can use to authenticate themselves to services with their user accounts assigned by Identity Management (SIAM).

Scope of functions

This TIK service is aimed at administrators/employees who operate software or a service and want to connect it to the central identity provider (IDP). 

TIK provides a central identity provider (IDP) that users can use to authenticate themselves to services with their user account assigned by Identity Management (SIAM). Many central services are already connected here (SAP, C@MPUS, WebEx, Matrix, etc.). It is expressly desired that additional services use the central login via single sign-on through the identity provider and refrain from using locally maintained accounts or LDAP authentication.
The prerequisite for connecting to the IDP is that the service is necessary for business purposes. If local user accounts are automatically created when logging in to the service, you must ensure that these user accounts are deleted when the corresponding user account in SIAM is deleted.
A service can be connected to the IDP using one of two protocols:   

  • OpenID-Connect (OIDC) or
  • SAML (Shibboleth).

Usually, software/services already provide one of these two options. If your software does not meet these requirements, you can use generic software:

If the login to a service has been configured via the IDP, the login process is as follows:

  • the user accesses the login page of the service/website/application
  • the service forwards the registration to the IDP of the TIK
  • the user enters their username, password, and possibly a second factor on the IDP login page
  • the IDP verifies the login credentials
  • notifies the service of the user's successful login if successful, and
  • transmits (if the user has consented) a specific set of attributes (e.g., name, email address, user ID, etc.)

If you would like to secure registration for your service via the IDP and require advice on this, please send an inquiry to: shibboleth-support@tik.uni-stuttgart.de

The information we require from you varies depending on the desired protocol:

If your software supports both protocols, we recommend OIDC, as it is less complex in terms of both setup and maintenance.

Connection with OIDC

In the context of OIDC, services, i.e., the software you want to connect, are called relying parties (RP). Each RP has a unique client ID and the IDP has an issuer ID. The IDP configuration can be loaded from the following URLs:

Some RP software can extract the necessary parameters from the above URL. If not, you will probably need to specify/configure the following in your SP:

  • issuer
  • authorization_endpoint, token_endpoint, userinfo_endpoint
  • jwks_uri

OIDC communication is secured using a shared key (not certificates). We will provide you with this ‘secret’ during setup.

If you would like to connect a service via OIDC, please send us a request to (shibboleth-support@tik.uni-stuttgart.de)  with the following information:

  • the name and purpose of the service
  • a contact person with contact information
  • the URL where users can sign up for the service
  • the redirect address(es) (redirect URL) that the IDP should call after successful login to the RP
  • attributes that are minimally required by the IDP (observe data minimization)

We will then provide you with the following information:

  • Client-ID
  • Secret
  • List of available scopes and claims (attribute sets and attributes)

An example of the data stored with us for an RP:

"client_id":        "mein-dienst.tik.uni-stuttgart.de"
"scope":             "openid profile email"
"client_secret": "ABC…XYZ"
"response_types":         ["code"]
"grant_types":  ["authorization_code"]
"token_endpoint_auth_method":          "client_secret_basic"
"redirect_uris": ["https://mein-dienst.tik.uni-stuttgart.de/auth/oidc/"]
"client_uri":       https://mein-dienst.tik.uni-stuttgart.de/login

Example of required attributes: Last name, first name, email address, unique anonymized user ID

Connection with SAML

Within SAML, a connected service is called a service provider (SP). In order for an SP to contact the IDP, it needs the IDP's metadata. This can be loaded from the following URLs:

Some SP software can extract the required parameters from the above URL. If not, you will probably need to specify/configure the following parameters in your SP:

  • entityID
  • X509Certificate
  • SingleSignOnService

This allows your SP to recognize the IDP and contact it. In order for the IDP to recognize and respond to requests from the SP, we also need metadata from your SP. This is usually provided in the form of an XML file on the SP. The URL for this file must be accessible to the IDP.

As part of this metadata, you need a key pair and the corresponding certificate for SAML communication between the SP and IDP. This SAML certificate may be valid for a maximum of 39 months, but can be self-signed. If you want to connect a web-based service, you will also need an SSL certificate for the appropriate DNS name.

If you would like to connect a service via SAML, please send us a request to (shibboleth-support@tik.uni-stuttgart.de) with the following information:

  • the name and purpose of the service
  • a contact person with contact information
  • the URL to the metadata (or the XML file itself)
  • the URL where users can sign up for the service
  • Information about who should be able to register for the service (only members of the University of Stuttgart or also external users from the DFN-AAI (https://download.aai.dfn.de/ws/2019/Grundlagen.pdf Site 8))
  • Attributes that are minimally required by the IDP (observe data minimization)

Example of SP metadata:

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="https://mein-dienst.hier.uni-stuttgart.de/shibboleth" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" >
     <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
           <KeyDescriptor use="signing">
                <ds:KeyInfo>
                      <ds:X509Data>
                           <ds:X509Certificate>MIIFJ ... Uzega8</ds:X509Certificate>
                      </ds:X509Data>
                </ds:KeyInfo>
           </KeyDescriptor>
           <KeyDescriptor use="encryption">
                <ds:KeyInfo>
                      <ds:X509Data>
                           <ds:X509Certificate>MIIFJ ... Uzega8</ds:X509Certificate>
                      </ds:X509Data>
                </ds:KeyInfo>
                <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
                <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
           </KeyDescriptor>
           <AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mein-dienst.hier.uni-stuttgart.de/shibboleth/saml/assertion"/>
     </md:SPSSODescriptor>
</md:EntityDescriptor>

Assurance Level in the Shibboleth Procedure

On the following page, you will find information about in the Shibboleth Procedure.

Further information

Support
To the top of the page