Project approval for “Swiss edu-ID Deployment Step 1”

Back in August 2016, SWITCH and seven partners (EPFL, FHNW, UNIFR, UNIGE, UNIL, UNISG and ZHAW) applied for project funding through in the framework of the P2/P5 programme of swissuniversities. Regular readers of our blog might remember, that we wrote about the submission and the nature of the proposal in the blog post Project for Deployment Step 1 in 2017 submitted which you are encouraged to re-read.

We are delighted to share with you the good news that this project received green light from the “Comité de pilotage du programme CUS P-2” at their meeting on 5 December 2016. This is good news for SWITCH and the university community as well as their stakeholders, as it marks the first of four “deployment steps” to implement the Swiss edu-ID roadmap until 2020.

This week, we received the formal approval letter annexed with an assessment note and additional obligations, which mean some additional homework for SWITCH (clarifications, reporting and project management obligations, as well as accommodating a cut in overall spending). Another good news for our project partners: these obligations are not impacting our partners’ work packages nor do they affect the support they receive from SWITCH.

We are looking forward to start the process of entering the deployment phase of the Swiss edu-ID roadmap and rolling out the SWITCH edu-ID service until 2020.


Advanced Access Management with SWITCH edu-ID

The SWITCH aai identity federation is based on one important concept: The separation of identity management (IdM) and access management (AM). Identity providers are trusted sources of a set of well defined attributes. For each user trying to access a service, the service itself decides based on his/her attributes if access to the service is granted or denied.

shared-attributes-basic

The identity provider in its purest form only manages general user information like name, age, email address, membership status at a university etc. This information is general and not specific to services. The service specific part is the way how attribute information can be combined by a service to build complex access rules like: “This service accepts math students and staff members”.

What if a group of services needs to share additional information about a user that is not part of the standard attribute set? For this case SWITCH has developed the shared attribute service for the edu-ID.

shared-attributes-extension

The shared attribute service consists of a database where additional attributes can be stored for each SWITCH edu-ID user. The contents of this database are not managed by the SWITCH edu-ID Identity Provider. Some external entities can access to the shared attributes database via an API, and set or delete attribute values for selected edu-ID users. When a user accesses to a service provider the shared attribute for that user is added to the standard attributes and sent to the service.

What effectively happens with shared attributes is that one part of AM (the part that is common to a group of services) is extracted from the services and centralized

First application: National Licences

The first application to use shared attributes is the National Licenses service. In the context of the national licenses some publishers grant access to users who satisfy a complex access rule. The user has to be a Swiss citizen, has to accept specific terms, must have been active during the last year and must not be blocked due to service abuse.

shared-attributes-natlic

A specially developed national licenses service registration platform checks if a user meets all the requirements of a user. If the user does meet the requirements, the flag national-license-compliant is set in the shared attributes database for that user. Consequently, services participating in the national licenses program get the additional attribute and grant access to licensed publications.

If a user does not meet all requirements, the national-license-compliant flag is removed. The user gets an explanation on the registration service and some indications how he or she could re-gain access to the national licenses program.

Note: The shared attributes service has been developed by SWITCH to solve a specific problem and to gain experiences with the concept. It is possible that the service will be replaced in the future by a more general group management service.


From project to service – introducing the SWITCH edu-ID service

Autumn 2013. Big things start small. An interuniversity working group captures floating ideas around user-centric identities, puts those ideas into a roadmap and proposes a name for it: Swiss edu-ID. The resulting document becomes one cornerstone of the national strategy, approved by the Swiss University Conference in April 2014. But it also marks the beginning of SWITCH’s efforts to implement the proposed Swiss edu-ID roadmap. swissuniversities supports this collaborative effort of SWITCH and the Swiss universities including their libraries.

Autumn 2016. The pilot service Swiss edu-ID V1.0 is around for well over a year. It allowed us to gain first operational experience in numerous pilot projects and a much clearer picture of what is yet to come. We also learned that some services start to rely increasingly on the availability of Swiss edu-ID, while others care more for the latest feature. Time is ripe to give both a home.

This is why SWITCH starts to use a new, distinct branding for the operational service emerging from the Swiss edu-ID project. The new branding honors the roots by keeping “edu-ID” in its name, but it also shows its operational home, adheres to the service naming guidelines of SWITCH and receives proper legal protection. The user-centric identity management service of SWITCH will be called the SWITCH edu-ID service.

You might notice in the not so distant future, that a new service will pop in the service catalogue of SWITCH, or that the “edu-ID login window” will look slightly different. But one thing won’t change: in its heart, the SWITCH edu-ID still carries those ideas captured in autumn 2013 by an interuniversity working group.


Real SSO feeling through the SPNEGO/Kerberos Login Flow for the Shibboleth Identity Provider v3

Windows users can now extend their SSO feeling to the SWITCHaai login page, provided their client is a member of a Windows domain. They no longer need to re-enter their username and password they’ve already entered to log in to the Windows desktop. Actually, Kerberos enabled non-Windows clients like Linux or Mac could profit of such enhanced SSO, too.

The Shibboleth Identity Provider (IdP) achieves this through SPNEGO-based Kerberos authentication (i.e. password-less web authentication via Kerberos). While version 2 of the Shibboleth IdP supported this through an extension, the Shibboleth IdP version 3 provides built-in support through the SPNEGO/Kerberos Login Flow authentication mechanism.

The SPNEGO/Kerberos Login Flow module was developed in co-operation by SWITCH and the Fachhochschule Nordwestschweiz (FHNW). As the FHNW already developed the extension for the IdP v2, they brought their existing experience into the project to re-implement the same functionality for IdP v3. Eventually, the SPNEGO/Kerberos Login Flow got an integral part of the Shibboleth Identity Provider version 3.2.0 in November 2015 and has been available since then.

The SPNEGO/Kerberos Login Flow has proven to run successfully on the IdPs of the Fachhochschule Nordwestschweiz and the Pädagogische Hochschule Bern, since these IdPs were migrated to IdP v3.

To use the SPNEGO-based authentication, the following prerequisites must be fulfilled:

  • A Kerberos infrastructure must be available (e. g. a Windows domain).
  • The IdP server must be registered as a Kerberos service at the Kerberos Key Distribution Center (KDC).
  • Kerberos client software must be installed on the IdP server.
  • The Shibboleth Identity Provider software must be configured accordingly.
  • The web browsers on the clients require specific configuration to use this authentication method.

Organisations being interested in using the SPNEGO-based authentication on their own IdP can find comprehensive documentation in the Shibboleth Wiki: SPNEGO/Kerberos Login Flow

SPNEGO-based authentication is also offered as an option to the Identity Provider Hosting service provided by SWITCH.


SWITCHaai Transition to Shibboleth Identity Provider v3 is 80% complete

Back in May 2015, the Shibboleth Consortium announced July 31st 2016 as end-of-life date for the IdPv2 code base. A redesigned IdPv3.1.1 is available since March 2015. One month later, SWITCH announced the initial version of the SWITCHaai specific IdPv3 installation guide. In June and September 2015, SWITCH offered well-attended IdP training courses [4] on how to configure IdPv3. Since then, the number of IdPv3 installations has gradually increased to the 80% level it reached just at the beginning of the autumn semester 2016.

The vast majority of the IdP administrators have installed, configured, tested and finally integrated the new version into their production environment. A big thank you to all of them that they gave their time to upgrade. Many administrators provided us valuable feedback on the IdP installation guide so that we could continuously improve it over time.
Several organizations decided to adopt the IdP Hosting service SWITCH offers instead of upgrading their own local installation. Today, SWITCH runs 17 production IdPs on our IdP hosting platform, including the ones for Swiss edu-ID, the Virtual Home Organization (VHO) and the IdP for the SWITCH staff members.

From about half of the remaining eleven IdPv2 instances we know that they will migrate to IdPv3 in the next few weeks. So hopefully by the end of 2016 almost everyone will have completed the transition.

The US InCommon Federation from time to time analyses the metadata of the eduGAIN interfederation service and publishes an interesting statistic on how many of the interfederation enabled IdPs are based on the Shibboleth open source software and run on IdPv3 or still on IdPv2. These numbers show that the percentage of IdPv3 in SWITCHaai is pretty high compared with most other federations listed.


Verify your Private Postal Address

The Swiss edu-ID is a user-centric identity. This means that the identity is managed by its owner who directly provides many pieces of identity information in the personal profile.

But can a user be trusted? Will users provide correct personal information for their Swiss edu-ID?

Although users rarely have a interest in providing wrong personal information about themselves, the answer to the above question is no. For this reason, Swiss edu-ID has implemented various processes to verify user information. All email addresses and mobile phone numbers are directly verified when a user enters them in the personal profile.

As of today, users also can have their private postal address verified.

Unverified addresses are marked by a grey verification icon with red question mark

Screen Shot 2016-09-01 at 13.37.30.png

Klicking the green arrow starts the verification process. A few days later, the user will receive a letter (yes – a real one on paper!) at the specified postal address with an activation code. After the user has entered the code in the Swiss edu-ID profile the address is verified. This is reflected with a golden verification icon in the profile

Screen Shot 2016-09-01 at 13.42.31.png

The first service relying on this new feature is the  National Licenses project of the Consortium of Swiss Academic Libraries. Their aim is to give private individuals access to scientific publications. The publishers of scientific publications require some sort of proof of a user, that he/she is living in Switzerland. By relying on the verifications done within the Swiss edu-ID the national licenses service does not have to implement its own verification processes.

Save