The edu-ID is a user-centric system in which users generally manage their account data themselves. And yet, some data relates to and is thus asserted by organisations like universities. Therefore, the edu-ID system provides several APIs for organisations so that they can manage data about users they are authoritative for. A new way to manage this data is the edu-ID administration interface for organisations, which is presented in this blog post.
A representative from a larger higher education organisation in Switzerland recently stated that they identify roughly 40 compromised user accounts on average per month. Extrapolating this number for all Swiss AAI users, this number would grow to more than 1’000 compromised accounts per month. Many of them are probably not even detected. Many of them probably belong to young students who may not always take proper care of their credentials. But every now and then, also staff members and professors learn about the nightmares of impersonation of their digital identity. So, how can edu-ID support SWITCHaai services to enhance authentication security? Continue reading
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
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?
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:
- A user from a cloud-only institution (without on-premises Active Directory) authenticates to Microsoft SaaS services, namely Office365
- A user from a hybrid institution (with on-premises Active Directory) authenticates to Microsoft SaaS services, namely Office365
- A user from a hybrid institution authenticates to a “modern” web app via SWITCHaai
- 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.
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):
- 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.
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.
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.
The steps defined here have been developed after consulting different sources. These were:
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)