Identity Models

Setup and basic configuration

Services who use Switch edu-ID for authentication are set up and configured as any other service in the SWITCH aai federation. Follow the guidelines for OpenID Connect and SAML services.

Intended Audience

The "intended audience" setting for an SP in the resource registry allows to include or exclude users of an entire organization on the level of an IdP. With SWITCHaai this was an intuitive setting. With SWITCH edu-ID this has become more tricky because an edu-ID account may contain one or more organizational aai accounts. The examples below should illustrate a few typical inclusion/exclusion scenarios.

Note that these intended audience settings are rather coarse access rules. If a user gets through to an SP because he or she belongs to the intended audience, the SP may still refuse access based on more fine grained rules evaluating user attributes.

Affiliation identity: only accept members of an organization

This case especially applies to existing services already supporting SWITCHaai. Such services usually don't need to change their configuration to support edu-ID.

In this configuration scenario, in order to get access to an SP a user has to be a member of an organization. It is irrelevant whether the organization has already integrated the edu-ID (edu-ID adopted) or not (SWITCHaai).

The following users are permitted to access the service:

  • Users of organizations who have adopted the edu-ID. All their users only have an edu-ID account with an affiliation which is linked to the organization. When accessing the SP the WAYF is presented to the user. It is recommended that the user chooses the organization to proceed and login with the edu-ID account. (Alternatively, the user could also choose "edu-ID" in the WAYF.)
  • Users of organizations who operate their own SWITCHaai IdP and have not yet adopted the edu-ID. When accessing the SP the WAYF is presented to the user to proceed.

The following users are excluded from the service:

  • Users who have no SWITCHaai account
  • Users who have an edu-ID account without an affiliation (i.e. without link to the organization)

Typical examples for SPs with this intended audience:

  • All SPs who want to limit the access to users who are affiliatied with an organization in the SWITCHaai federation. In particular "private" users who only have an edu-ID account and who are not university members should not be allowed to access the service

Setting in the resource registry:

rr-affiliation-only

Personal identity: only accept users with an edu-ID account

In this configuration scenario only users get access to an SP who have an edu-ID account. Regardless of whether the user has an affiliation with an organization or not - the SP recieves the attributes of the personal part of an edu-ID identity.

The following users are permitted to access the service:

  • All users with an edu-ID account. When accessing the SP, the user is redirected to the edu-ID login page without detours. No WAYF is displayed.

The following users are kind-of excluded from the service:

  • Users who have no edu-ID account or who only have a SWITCHaai account
    → Important note: Users without edu-ID account can create one on the fly by clicking the "create account" button on the edu-ID login page. So after having created an edu-ID account, a user will nevertheless be automatically sent to the SP.

Typical examples for SPs with this intended audience:

  • All services with low barriers to entry: e.g.
    • Registration page for prospective students at a university
    • Linking service at a university for linking-after-admission
    • Registration page for private users at a public library
    • Registration page for events at an organization
  • Services requiring specific edu-ID functions like two-factor-authentication, non-academic users, attributes verified by edu-ID.

Setting in the resource registry:

rr-eduid-only

Since the selection of an IdP for the user is not required for login, the discovery service (WAYF) should be deactivated. This can be done with the following setting in the shibboleth2.xml configuration file in the <SSO> Element:

<SSO entityID="https://eduid.ch/idp/shibboleth">
 SAML2
</SSO>

For edu-ID only services it is recommended to use one of the official edu-ID login button designs.

Optionally, an SP can get limited affiliation information by requiring some of the following attributes:

  • swissEduIDLinkedAffiliation
  • swissEduIDLinkedAffiliationMail
  • swissEduIDLinkedAffiliationUniqueID

To use one or more of the above attributes, you need to add them to the configuration file attribute-map.xml of your Shibboleth SP:

<!-- SWITCH edu-ID Linked Affiliation -->
<Attribute name="urn:oid:2.16.756.1.2.5.1.1.1029" id="swissEduIDLinkedAffiliation"/>
 
<!-- SWITCH edu-ID Linked Affiliation E-Mail -->
<Attribute name="urn:oid:2.16.756.1.2.5.1.1.1031" id="swissEduIDLinkedAffiliationMail"/>
 
<!-- SWITCH edu-ID Linked Affiliation Unique ID -->
<Attribute name="urn:oid:2.16.756.1.2.5.1.1.1032" id="swissEduIDLinkedAffiliationUniqueID"/>

Furthermore, you need to notify the SWITCH edu-ID Team at eduid-support@switch.ch to get these attributes.

Extended identity: Only accept users with an edu-ID account (extended attribute model)

The extended attribute model consists of SWITCHaai attributes that contain extensive information about linked affiliations.

An extended model service is configured the same as with the edu-ID only configuration. The SP gets additional affiliation information via the backchannel by accessing the affiliation API.

Affiation identities and personal identities combined

In this configuration configuration scenario users are accepted as well as users who are members of an organization.

Typical examples for SPs with this intended audience:

  • Learning management systems that are open for regular students (with affiliation) and further education students (without affiliation)
  • Libraries with online resources for university members and the public.

Setting in the resource registry:

rr-all-permitted