SWITCH Identity Blog

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


E-ID law: SWITCH contributing to parliamentary hearing

At its meeting on 1 June 2018, the Federal Council adopted a dispatch to Parliament containing a draft for an E-ID law (see corresponding press release in DE, FR and IT; for follow-ups see “18.049 Business of the Federal Council”).

The National Council’s legal commission now runs the business. On 15.11.2018, it held a hearing with representatives of industry, public corporations, potential providers of E-ID solutions and interested parties from civil society. As a potential provider, SWITCH was able to take part in this hearing.

This draft E-ID law largely follows the preliminary draft consulted last year (press release with link to consultation report at page bottom). It does not come as a surprise, therefore, that the position of SWITCH expressed towards the preliminary draft also applies to the new draft law – including the criticism voiced therein. Continue reading


Wearing Many Hats

As a university member you usually have a unique role – you are either student, or teacher, or staff. In not so rare cases, however, a person has several roles at the same time, e.g. as a student and employee. How do universities deal with this situation today in SWITCHaai, and how is it covered in SWITCH edu-ID?

Continue reading


Microsoft Integration Demo

Summary

For many Higher Education Institutions in Switzerland, the integration of their identity and access management solution with Microsoft products is an important requirement. This also applies before / when adopting the SWITCH edu-ID. To this end, SWITCH has developed the necessary building blocks to demonstrate that such an integration is possible. This enables users to benefit from cloud offerings such as Office 365 or Microsoft Azure services with their usual login credentials.

The four demo use cases that were established are:

  1. A user from a cloud-only institution (without on-premises Active Directory) authenticates to Microsoft SaaS services, namely Office365
  2. A user from a hybrid institution (with on-premises Active Directory) authenticates to Microsoft SaaS services, namely Office365
  3. A user from a hybrid institution authenticates to a “modern” web app via SWITCHaai
  4. A user from a hybrid institution authenticates via Kerberos to a local application via his SWITCH edu-ID

Demo case 3 is straightforward, because SWITCH edu-ID is just a particular SWITCHaai Identity Provider (IdP) running the same software (Shibboleth) as most of the other institutional Identity Providers in SWITCHaai. Its consists of simply using the SAML 2.0 protocole which has been supported already for a long time by all SWITCHaai Identity Providers.

For the other demo cases, we had to integrate SWITCH edu-ID with Microsoft’s underlying cloud identity management system, the Azure Active Directory. In the following sections, we describe, how this can be done.

Implementation Components

To authenticate against Microsoft’s Azure Active Directory using a third-party Identity Provider like Shibboleth, Microsoft requires two non-standard -(SWITCHaai) attributes (or claims):

  1. ImmutableID
  2. userPrincipalName (UPN)

The first thing to do as a prerequisite is hence, to extend the current SWITCH edu-ID LDAP directory with an additional LDAP scheme containing these two attributes.

In order to provide these attributes, the SWITCH edu-ID Identity Provider configuration was extended with an attribute filter policy, releasing the attributes, and a fitting attribute resolver, loading the attributes from the underlying LDAP.

The second step is to exchange metadata between Microsoft Online and SWITCH edu-ID. Microsoft Online provides its metadata on a public URL, SWITCH edu-ID provides signed metadata as part of the SWITCHaai federation.

Then, Microsoft’s Online Services had to be configured for the Federated Authentication, forwarding all authentication requests for the covered domain(s) to the SWITCH edu-ID IdP.

The last necessary step was to provision the users in Azure Active Directory. This is necessary, because Azure Active Directory cannot provision a user on-the-fly based on a SAML assertion, and needs to assign a usage location and license to every user beforehand. Since this constitutes a transfer of personal information to Microsoft, it is recommended to let all users consent to this first.

In the case of hybrid institution, the users are synchronised from the institution’s on-premise AD to the Azure Active Directory via AAD Connect. In this case, the users’ ImmutableID attribute stored in the edu-ID LDAP directory needs to correspond to the ImmutableID used by AAD Connect. A mechanism for synchronising the ImmutableID and the userPrincipalName between the on-premise AD and the edu-ID will be made available soon.

In the case of the cloud-only institution, for each provisioned Azure AD user, an appropriate ImmutableID must be generated, stored in the edu-ID LDAP directory and synchronised with the Azure Active Directory.

Limitations

Microsoft’s implementation lacks some features that are considered best-practice in Higher Education Identity Federations.
• The Microsoft Online metadata is unsigned, which is unusual in Higher Education Identity Federations, but they are provided over a https connection.
• A metadata aggregate cannot be consumed and automatic hourly reload of metadata is unsupported. Therefore, metadata changes from the federation have to be manually fed to Microsoft.
• Microsoft does also not support encrypted SAML assertions, forcing any Shibboleth Identity Provider interacting with it to disable encryption.

Final Thoughts

The authentication to Microsoft services via the SWITCH edu-ID is generally feasible, enabling organizations to keep a single identity and not needing to create a second set of credentials for Microsoft Office365 and other solutions. However, the security level, we are normally used to and is considered a best-practice in Higher Education Federations, had to be lowered a little bit.

Also, Microsoft’s requirements for interoperation do seem to differ from the Higher Education Interoperation Profiles and seem to change frequently without notice. Therefore, do not be surprised, if some information in the referenced documentation or in this article has become obsolete or outdated at the time you read it.

References

The steps defined here have been developed after consulting different sources. These were:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp

https://github.com/zckb/azuread-shibboleth-docs

https://wiki.shibboleth.net/confluence/display/IDP30/Office+365

https://wiki.sunet.se/display/SWAMID/How+to+use+Shibboleth+Identity+Provider+v3+with+Office+365


Submit your Sub-Project for Planning and/or Adoption!

In August we’ve submitted our last project application for Swiss edu-ID – the Deployment Steps 3 & 4 – to swissuniversities. Intended is a two-year project during 2019 and 2020 that contains just as before two parts:

  • further development of features (functional extensions) and
  • planning and adoption activities of universities (deployment).

In order to allow non-bureaucratic and more agile handling especially for the planning phases, universities can now requests for third-party funding twice a year and therefore can become much easier a project partner and start funded activities.

If third-party funding would be beneficial to your university, please consider to submit a sub-project on the following dates:

  • 30.11.18 (project start January 2019)
  • 31.5.2019 (project start July 2019)
  • 30.11.2019 (project start January 2020)
  • 31.3.2020 (if there is still funding available; project start May 2020)

You find the one-page application form on our project website.

The application must be addressed to SWITCH, but the same rules apply as for projects submitted to swissuniversities (at least 50% own funds, reporting etc.).*

Universities with no need for third-party funding can start a sub-project – in consultation with us – at any time.

Don’t hesitate to contact us and join the group of already 24 universities!

* NOTE: This procedure is subject to approval by swissuniversities (expected for December 2018)


Go for next Deployment Step

The project Deployment Step 2.2, submitted in February, is now approved by swissuniversities.

Participating Universities

From August on several universities will start the adoption planning, supported by federal funds in the framework of the Deployment Step 2 phase:

  • Berner Fachhochschule
  • Fachhochschule St. Gallen
  • Haute école spécialisée de Suisse occidentale
  • Hochschule für Technik und Wirtschaft Chur
  • Hochschule für Wirtschaft Zürich
  • Pädagogische Hochschule Bern
  • Université de Neuchâtel
  • Zürcher Hochschule der Künste.

The following universities plan the implementation of SWITCH edu-ID in 2018/19:

  • FernUni
  • Hochschule Luzern
  • Pädagogische Hochschule Schwyz
  • Pädagogische Hochschule Zug
  • Université de Lausanne
  • Universität Luzern
  • Universität St. Gallen
  • Zürcher Hochschule für Angewandte Wissenschaften.

The list of participating organisations is regularly updated and available at https://projects.switch.ch/eduid/adoption/
Continue reading


1 Comment

There Can Be Only One!

As a child of the 80’s, of course I have seen the movie “Highlander”. In our “clone wars” (referencing Star Wars) against edu-ID duplicate accounts, I therefore remember the famous high lander quote “there can be only one”. Slightly adapted, this quote fits: “There can be only one edu-ID account per person”. Thanks to the automatic merging process described in this article, we now have the weapon in our hands to reach this goal.

Continue reading


3 Comments

Clone Wars

Duplicate user accounts on a single system are sooner or later causing a nightmare. One ambition of the SWITCH edu-ID has always been the prevention of duplicate user accounts. However, only a few weeks after the edu-ID launch in 2015 we already found indications for a couple of duplicate accounts. How did that come about and what can we do to prevent duplicate accounts?

Continue reading


The SWITCH identity federation – a look beyond its borders

The SWITCH identity federation was conceived almost two decades ago. The SWITCHaai service, implementing its concepts, has been in operation for over a decade. Today, the SWITCH edu-ID service is in its initial stages to become its successor, and it is still following the same model: to stay the identity federation of the Swiss academic community. That is reason enough to address those two rather fundamental questions:

  1. Are national identity federations still the right approach to satisfy the needs of the academic community – a community with increasing international collaboration?
  2. Will emerging e-ID services, or services like SwissID, eventually replace the SWITCH identity federation?

Both question the remits of the current solution: national and academic. But they differ in perspective: while the first is questioning the national remit, the second is questioning the academic-only context. Continue reading


One edu-ID – multiple roles

This is a core promise of the SWITCH edu-ID: An individual should be able to use one single digital identity to authenticate, while at the same time being able to choose the appropriate organisational role – or, using a more technical and precise term, the appropriate affiliation – in which to enter a service.

For members of organisations which have already adopted the SWITCH edu-ID, this concept has now arrived in the real SWITCH edu-ID world. The module called “affiliation chooser” is now executed right after authentication. It lets the user choose the appropriate affiliation, before consenting to attribute release and service access.

The affiliation chooser is intended as an intelligent replacement for the well-known discovery service (WAYF). The good thing about the affiliation chooser is that it knows when to show a choice at all. Unlike the WAYF, it only bothers the end user with its question when it really needs to. If e.g. the end user has only one affiliation, then there’s no real choice. Most edu-ID users have just one single affiliation to an organisation, if at all, which is then the one to present to the service. On the other hand, if the service allows only one affiliation, then again, this is the one to check against, even in the rare case when the user has more of them. In a more complex scenario, the affiliation chooser would actually do some set operation. The intersection of all affiliations the service is intended for, with all affiliations that an end user has, may actually contain zero, one, or more items:

  • If no affiliation remains, then the user, although correctly authenticated, cannot be admitted to the service, as none of his affiliations would fit. This check is now being done by the edu-ID IdP, before the user is sent to the service.
  • If there remains exactly one out of this intersection, then it’s the one to choose. No need to bother the end user with a choice if there’s just one item to choose from.
  • If multiple affiliations remain, then this is where the end user actually sees something. A dialog box similar to the one in figure 1 is shown, and the end user has to choose the affiliation – given by a certain set of attributes – to present to the service. Based on these attributes, the service can then assign the appropriate privileges and access rights.

 

Screen-Shot-2018-03-26-at-10.16.29.png_611707229

Figure 1: The Affiliation Chooser

What’s in for the end user?

Once the organizations the users are affiliated with adopt the SWITCH edu-ID, the end users will see much fewer possible choices in the affiliation chooser than they currently see in the discovery service. At the point of writing this article, only SWITCH has adopted the SWITCH edu-ID, therefore this currently only applies to SWITCH staff members.

What’s in for the services?

When registering with the federation, services declare their “intended audience”, and thus give an upfront indication about which organizations users must have an affiliation with, in order to be allowed on the service. This indication is picked up by the affiliation chooser which then puts it into an intelligible form and thus helps in pre-filtering the users arriving at the service.

Certain services allow for “private identities”, i.e. without any affiliation to an organisation. In that case, the affiliation chooser flags this possibility separately. Figure 1 shows this as “Private Person” option.

Future services might be able to cope with more than just one affiliation at a time, as the “extended attribute model” in the Swiss edu-ID Architecture suggests. For such services, the affiliation chooser won’t be needed, as no affiliation would have to be chosen at that point.


Swiss edu-ID Deployment: Next Steps

Project for Deployment Step 2 in 2018/19 submitted

Within this next project phase – once approved by swissuniversities – the first three universities will implement SWITCH edu-ID:

  • Université de Lausanne
  • Universität St. Gallen
  • Zürcher Hochschule für Angewandte Wissenschaften.

They’ve developed their individual integration plan during 2017 (Deployment Step 1). As the other four participating universities they have considerably contributed to elaborate and sharpen adoption scenarios for linking of new and current members and for managing affiliations.

Eleven universities will start implementation planning: Berner Fachhochschule, FernUni, Fachhochschule St. Gallen, Haute école spécialisée de Suisse occidentale, Hochschule Luzern, Hochschule für Technik und Wirtschaft Chur (HTW Chur), Hochschule für Wirtschaft Zürich, Pädagogische Hochschule Bern, Pädagogische Hochschule Schwyz (PHSZ), Université de Neuchâtel and Zürcher Hochschule der Künste.

Continue reading


The Transition of a University to edu-ID

In 2017, seven universites have started planning their adoption of SWITCH edu-ID. Together with the edu-ID project team each university organized 2-4 workshops to elaborate an individual integration concept and to determine a time schedule for the transition.

It was no surprise to see that the IT landscape and identity management (IdM) processes of the universities are fairly different. Based on the workshops we were however able to identify and document a few major categories which may serve as source of ideas for other universities.

Continue reading


SWITCH adopts edu-ID

Wait!? We all know that SWITCH develops edu-ID – so what does adopting edu-ID mean?

It is true that SWITCH as the operator of the AAI federation develops edu-ID. On the other hand, the organization SWITCH with its IdP is also a SWITCHaai Home Organization in the AAI federation. In this post we will describe how the organization SWITCH integrated edu-ID, allowing it to turn off its own IdP.

Continue reading


Identity Management Evolution

What does it take for a university to adopt the SWITCH edu-ID? This is the question SWITCH and seven partners (EPFL, FHNW, UNIFR, UNIGE, UNIL, UNISG and ZHAW) are addressing in the project “Swiss edu-ID Deployment Step 1” as part of swissuniversities’ program «Scientific information». The project advanced nicely and would justify an article on its own. But let’s draw your attention to an interesting side product of this project: we learned how electronic identities are managed in our community – and how the approaches are evolving over time and why.

Continue reading