SWITCH Identity Blog

The Identity Blog puts the spotlight on identity management, digital identities, identifiers, attributes, authentication and access management.

SPNEGO (Kerberos) authentication with SWITCH edu-ID

Leave a comment

Back in 2016, Daniel Lutz showed how the Shibboleth IdP can offer a real SSO feeling by reusing an already existing authentication token on domain-joined windows clients. SWITCH has now extended this concept in order to offer it to all organisations that have migrated to the SWITCH edu-ID.

Are you working on a domain-joined windows client? Would you want to automatically log into services protected by SWITCHaai/SWITCH edu-ID? Then read on.

With this feature you can save clicks when logging in at the SWITCH edu-ID IdP:

 

Concept

SWITCH is operating the necessary infrastructure for the so-called Kerberos cross-realm authentication, in particular an own Kerberos KDC service realm: @EDUID.CH. This edu-ID realm is trusting the realms of the organisations in order to authenticate end users (unilateral trust is sufficient). The infrastructure is designed such that multiple organisations (@UNI-A.CH, @UNI-B.CH, @UNI-C.CH) can be included and served:

When an authentication takes place, the six steps depicted and described below are executed, without the end user noticing much:

  1. Having logged in and working on a domain-joined workstation (the client), the end user may surf to some service provider (SP) in the SWITCHaai federation, from where she is then redirected to the SWITCH edu-ID identity provider (IdP). The IdP notices that the activation condition is met, and offers SPNEGO authentication. (In case the activation condition is not met, the IdP doesn’t offer this option.)
  2. The client then requests a ticket granting ticket (TGT) at the own Windows key distribution center (KDC) labelled with @UNI-A.CH, in order to obtain a service ticket (ST) at the SWITCH edu-ID KDC (@EDUID.CH) later on. The client must be configured accordingly, e.g. through „group policy object“ (GPO).
  3. The Windows KDC provides the requested TGT ticket. Data destined for the SWITCH edu-ID KDC are encrypted accordingly, i.e. with the specific shared secret.
  4. With this TGT, the client then requests a service ticket (ST) at the SWITCH edu-ID KDC (@EDUID.CH), in order to obtain access to the SWITCH edu-ID IdP (https://login.eduid.ch).
  5. The SWITCH edu-ID KDC (@EDUID.CH) returns the requested ST, based on the initially established cross-domain trust. Data destined for the SWITCH edu-ID IdP are encrypted accordingly, i.e. with the specific service principal password.
  6. The SWITCH edu-ID IdP decrypts and validates the ST and can thus grant access. The IdP also obtains the end user identifier, i.e. the Kerberos principal name, e.g. p.etudiant@UNI-A.CH.

As mentioned before, end users usually don’t see anything of all that when working on a domain-joined windows workstation. However, organisations intending to offer this service need to do some preparation on their side. go through the following preparation steps:

  • Contact the SWITCH edu-ID team: We will guide and assist you when you go through the following steps.
  • Synchronisation of the Kerberos principal name: For all affiliations (aka linked identities) or accounts in the Active Directory of the organisation, for which this SPNEGO authentication has to work, must have their Kerberos principle name <sAMAccountName>@<DOMAIN> synchronised into the SWITCH edu-ID user directory, through either push or pull. The corresponding SWITCH edu-ID attribute is called extKerberosPrincipalName.
  • Trust configuration: The trust with the SWITCH edu-ID Kerberos realm must be established, usually through a shared secret.
  • Configuration of the SWITCH edu-ID Kerberos realm for clients: This is done through „group policy object“ (GPO).
  • Configuration of the client’s browser: The browser on the clients where users shall profit from the smooth authentication and the real SSO feeling, must be configured accordingly. Appropriate fleet deployment is certainly helpful for this point.
  • Specification of the activation condition: The activation condition must be defined and communicated towards the end users. While IP address ranges have been used in the past, we nowadays would rather recommend a predefined identifier in the user agent string of the browser.

This comfy feature helps your staff and students save hundreds or thousands of clicks per day. Contact the SWITCH edu-ID team to see whether it pays off also for your organisation. For the complete technical background, please have a look at our documentation.

 

 

 

Leave a Reply