Site icon SWITCH Identity Blog

SPNEGO (Kerberos) authentication with SWITCH edu-ID

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:

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.

 

 

 

Exit mobile version