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 edu-ID federation. Follow the guidelines for OpenID Connect and SAML services.

Please check out the description for all identity models on the Identity and Attributes page and its subpages:

If more than one identity can be selected by the user, the Identity Chooser is shown to them.

Intended Audience

The "intended audience" setting for a service in the resource registry allows to include or exclude users of an entire organization or type of organization on the level of an IdP. Each Switch edu-ID account may contain one or more linked affiliations. 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 a service because he or she belongs to the intended audience, the service 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 the edu-ID federation (formerly SWITCHaai). Such services usually don't need to change their configuration to support the Switch edu-ID IdP.

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

The following users are permitted to access the service:

  • Users of organizations who have adopted the edu-ID: All their users have an edu-ID account with an affiliation which is linked to the organization.
    • When accessing a SAML service, the Discovery Service (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.)
    • When accessing an OIDC service, the edu-ID login is directly presented to the user, and they can select the organization in the Identity Chooser (shown only if they have more than one available affiliation).
  • Users of organizations who operate their own IdP and have not yet adopted the edu-ID: Not all their users have an affiliation.
    • When accessing a SAML service, the Discovery Service (WAYF) is presented to the user to proceed, where they have to select the organization (and not "edu-ID").
    • When accessing an OIDC service, the edu-ID login is directly presented to the user. If they have an affiliation, they can select it in the Identity Chooser (shown only if they have more than one available affiliation).

The following users are excluded from the service:

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

Typical examples for services with this intended audience:

  • All services that want to limit the access to users who are affiliatied with an organization in the Switch edu-ID 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 who have an edu-ID account get access to the service. Regardless of whether the user has an affiliation with an organization or not, the service recieves the attributes of the personal part of the edu-ID identity.

The following users are permitted to access the service:

  • All users with an edu-ID account. When accessing the service, 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 an account in another IdP of the federation
    → 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 service.

Typical examples for service 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 multi-factor authentication (MFA), 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.

 

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

Optionally, a service can get limited affiliation information by requiring some of the following attributes:

  • swissEduIDLinkedAffiliation
  • swissEduIDLinkedAffiliationMail
  • swissEduIDLinkedAffiliationUniqueID

The extended attribute model consists of the personal edu-ID identity, augmented with this additional information about linked affiliations. Such an extended model service is configured the same as with the edu-ID only configuration (see above).

The service can also get additional affiliation information via the backchannel by accessing the Affiliation API. You need to notify the Switch edu-ID Team at eduid-support@switch.ch to get access to these attributes.

SAML-specific guidelines for extended identity

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"/>

Affiliation Identities and Personal Identities combined

In this configuration scenario, the service accepts users who are members of an organization or have an edu-ID account.

Typical examples for services 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