Testing Scenarios

To make sure that the migration to the edu-ID passes off as smoothly as possible, organisations are encouraged to test various processes and components before and during the migration. This page describes various testing scenarios and possibilities from the perspective of a migrating organisation.

See Testing for general information, e.g. differences between the production and test versions of the edu-ID service.

There are mainly two areas to test:

The following sections describe the details. 

Testing AAI login on edu-ID IdP with organisation affiliation

It's important to make sure that after the migration to the edu-ID, the AAI login works as before for all of the organisation's members, i.e. exactly as with the organisation's existing IdP. Especially, access to all of the organisation's critical services should be tested with great care. This includes whether AAI login to the service works in general and if the logged in users can access all of the service's data as before.

To allow testing the AAI login on the edu-ID IdP as an organisation member (i.e sending the same SAML assertion to services as the organisation's existing IdP would do), SWITCH will need to adapt the configuration of the edu-ID IdP such that it can fully simulate the organisation's existing IdP. This includes copying the SAML certificate (and the corresponding private key) from the organisation's existing IdP and copying some data stored on the organisation's IdP (such as Persistent ID values and attribute release consents).

SWITCH will configure the Staging IdP prior to an organisation's adoption of the edu-ID such that the organisation can test their important services and see how the login will work on the edu-ID IdP after the migration took place. The Staging IdP will be made available to a limited set of people to run tests.

Preparing for testing involves the following tasks:

Organisation SWITCH

Provide SWITCH with the SAML certificate and private key of the organisation's existing IdP.

SWITCH needs to install the existing IdP's SAML certificate on the edu-ID Staging IdP, such that this IdP can simulate the organisation's existing IdP.
Provide SWITCH with Persistent ID and attribute release user consent data on the existing IdP. SWITCH needs to import this data on the edu-ID Staging IdP, such that services get the same Persistent ID values and that already given consents are honored.
   

During the setup on the Staging IdP for an organisation, SWITCH will setup some additional DNS names for the edu-ID IdP that are dedicated to the organisation and communicate them to the organisation. In the table below, these dedicated DNS names are the ones starting with <orgid>.

Supported Testing Scenarios

The Staging IdP supports the following login scenarios:
(See the section "Examples" below to see how to run the actual tests.)

Attribute Model Affiliation/
Identity
Scenario Affiliation
Chooser
Login flow type "hosts" entry required on client
Remarks/Conditions IdP
DNS
name
Classic Organisation Emulate Pre-Migration
Legacy AAI Login
No
(only if user has multiple accounts at same org)
Start login on SP, as usual
(choose organisation in WAYF)
Yes2  

Current IdP's DNS name
e.g. aai-login.unidemo.ch

Classic Organisation Access AAI SP as organization member No
(only if user has multiple accounts at same org)
Special login link, start login on IdP1 No SP must support Unsolicited Login3

<orgid>.login.staging.eduid.ch
e.g. unidemo.login.staging.eduid.ch

Compose Link

Classic Private
Identity
Access AAI SP as private person Yes (if SP accepts all audiences) Start login on SP, as usual
(choose edu-ID in WAYF)
Yes2   login.eduid.ch
Classic Private
Identity
Access AAI SP as private person Yes (if SP accepts all audiences) Special login link, start login on IdP1  No SP must support Unsolicited Login3 login.staging.eduid.ch

Compose Link
Extended Private
Identity,
Extended
Attributes
Access native edu-ID SP (or edu-ID only SP) No Start login on SP, as usual
(choose edu-ID in WAYF)
Yes2   login.eduid.ch
Extended Private
Identity,
Extended
Attributes
Access native edu-ID SP (or edu-ID only SP) No Special login link, start login on IdP1 No SP must support Unsolicited Login3 login.staging.eduid.ch

Compose Link

 Remarks:

  1. The login flow can't be started at the service as usual, but always starts at the edu-ID IdP, using Unsolicited Login. The special login link URL explicitly refers to the Staging IdP.
    This link can be assembled via the Link Composer below. Choose the "IdP DNS Name" suitable for your organisation, as communicated by SWITCH.
  2. Create appropriate entries in the "hosts" file on the client system.
    Add entries for the DNS names specified in the table in the column IdP DNS name, refering to the IP address of the Staging IdP: 130.59.118.139 (IPv6: 2001:620:0:1006:21a:4aff:fede:97). Adapt the DNS names to suit your organisation and as communicated by SWITCH.
    See e.g. Wikipedia for more information about the "hosts" file.
  3. Unsolicited Login means that the login flow starts on the IdP and the user hasn't accessed the service (SP) before. That is, the service unsolicitedly gets a SAML assertion from the IdP without prior SAML authentication request. Some SPs don't accept such assertions. For such SPs, these login scenarios don't work.
    (If the login is started at the SP, the SP always looks up the IdP's service location in the metadata based on the IdP's EntityID. There's no way of overriding the IdP service location the SP will use.)

Link Composer

SP EntityID: (EntityID of SP to be tested)

SP Target URL: (Send user to this location at the SP after the login)

SP ACS: (Optional; required if SP supports multiple assertion consumption service locations)

IdP DNS Name: (DNS name according to the table above)


Generated Link:


Open link in new window

Suitable hosts file entries (for test cases requiring them):

  • File on macOS/Linux: /etc/hosts
  • File on Windows: C:\WINDOWS\system32\drivers\etc\hosts
130.59.118.139                    login.staging.eduid.ch
2001:620:0:1006:21a:4aff:fede:97  login.staging.eduid.ch

Examples

Start login on SP, "hosts" entry required

Attribute model: Classic
Affiliation/Identity: Organisation
Login flow type: Start login on SP

This test case verifies if accessing a service as an organisation member via the edu-ID IdP will work the same as via the organisation's existing IdP. The user chooses the organisation in the WAYF on the service, as usual. Then, the user is redirected to the edu-ID Staging IdP instead of the organisation's existing IdP (DNS override via "hosts" entry). The user needs to log in using the edu-ID account. Then, the user should get access to the service as an organisation member (i.e. getting access to the existing user profile data).

Instructions to run this test:

  • Choose the service (SP) you want to test.
  • Go to the Link Composer form above.
  • Enter your Organisation's existing IdP DNS Name, e.g. aai-login.unidemo.ch.
  • Add the shown "hosts" entries to the "hosts" file on the client computer you use for testing. (Don't forget to remove it again after the test.)
  • Access the service, as usual.
  • Choose your organisation in the WAYF.
  • Log in via the edu-ID Staging IdP.
  • Verify if you can access the service as usual.

Example values for the Link Composer form:

  • IdP DNS Name: aai-login.unidemo.ch

 

Special login link, start login on IdP, no "hosts" entry required

Attribute model: Classic
Affiliation/Identity: Organisation
Login flow type: Special login link, start login on IdP

This test case verifies if accessing a service as an organisation member via the edu-ID IdP will work the same as via the organisation's existing IdP. This test emulates the user choosing the organisation in the WAYF on the service, as usual. Then, the user is redirected to the edu-ID Staging IdP instead of the organisation's existing IdP. The user needs to log in using the edu-ID account. Then, the user should get access to the service as an organisation member (i.e. getting access to the existing user profile data). (Note: This test stats the login at the IdP. It requires that the SP supports "unsolicited logins".)

Instructions to run this test:

  • Choose the service (SP) you want to test.
  • Go to the Link Composer form above.
  • Find the SP's EntityID by entering the service's DNS name in the field SP EntityID and select the service from the suggestions.
  • Adapt the SP Target URL, i.e. the URL where the user should be redirected to after the login, as required. (This is specific to the service. If unsure, just keep the URL as is.)
  • Enter the IdP DNS Name, enter the value <orgid>.login.staging.eduid.ch. Replace <orgid> by the label assigned to your organisation. (Ask at eduid@switch.ch if unsure.)
  • Open the generated link in a new browser window or tab.
  • Log in using your personal edu-ID or a technical edu-ID account for testing.
  • Verify if you can access the service as usual.

Example values for the Link Composer form:

  • SP EntityID: https://attribute-viewer.aai.switch.ch/shibboleth
  • SP Target URL: https://attribute-viewer.aai.switch.ch/aai
  • IdP DNS Name: unidemo.login.staging.eduid.ch

 

 

Testing Attribute Exchange

Depending on the chosen mechanism for the attribute exchange (i.e. synchronisation of affiliations), different testing approaches apply.

For organisations using Attribute Push via Affiliation API

Note: For testing attribute synchronisation via the Affiliation API, i.e. testing the organisation's Affiliation API client implementation, it is important to know that affiliations are being linked with edu-ID accounts either in the test or the production version of the edu-ID service, depending on which instance of the Affiliation API is accessed (test or production). Consequently, an account at the organisation (i.e. an affiliation) is linked either with a test edu-ID account or a production edu-ID account, which have different edu-ID identifiers (identifiers of test edu-ID accounts are always prefixed with "0000-"). Since the edu-ID identifier of the linked edu-ID account must be stored in the linked organisation's account, linking test edu-ID accounts with organisation production accounts might not be possible in general.

Examples:

  • A dedicated test account at the organisation can be linked with either a known test edu-ID account or a known production edu-ID account. The edu-ID identifier of the chosen edu-ID account needs to be stored in the organisation's account.
  • A specific personal account at the organisation (staff or student account) can be linked with either a known test edu-ID account or a known production edu-ID account. The edu-ID identifier of the chosen edu-ID account needs to be stored in the organisation's account.
  • Linking other organisation accounts usually involves some registration process where the owner of the edu-ID account to be linked needs to log in with his/her edu-ID account to proof ownership. Therefore, this is usually restricted to production edu-ID accounts.

Which set of organisation accounts can be used for testing in the test environment depends on the implementation and deployment of the organisation's Affiliation API client.

In the following, we describe some concrete testing examples:

Link dedicated test accounts with edu-ID test accounts (technical accounts) in the test environment

Here we assume that the test account is in the organisation's test directory. If it's in the production directory, see the next section.

Testing procedure:

  • Choose an organisation test account to be linked with an edu-ID technical account.
  • Go to the organisation administration interface of the test environment: https://test.eduid.ch/web/organisation-administrator/
  • Create a new technical account.
  • Write down (or copy) the "edu-ID" identifier (UUID) of the new technical account
  • Store the "edu-ID" identifier in the organisation test account in the appropriate dedicated attribute.
  • Run the Affiliation AP client on the organisation test account.

For the Affiliation API operations, the organisation test account's swissEduPersonUniqueID value is used as key identifier, and the "edui-ID" identifier is used to specify the edu-ID account to link to.

Link specific pesonal accounts with edu-ID test accounts (technical or personal accounts) in the test environment

Here we assume that the personal account is in the organisation's production directory. The production account is linked with an edu-ID account in the edu-ID test environment.

Testing procedure:

  • Choose an organisation production account to be linked with an edu-ID test account (either a personal account or a technical account).
  • Create a new personal edu-ID at https://test.eduid.ch/ (if not already created), or create a new technical account in the organisation administration interface at https://test.eduid.ch/web/organisation-administrator/.
  • If using a technical account, write down (or copy) the "edu-ID" identifier (UUID) shown in the organisation administration interface. If using a personal account, go to https://test.eduid.ch/, log in, go to https://test.eduid.ch/Shibboleth.sso/Session and write down (or copy) the "edu-ID" identifier (UUID) shown in the attribute Swiss_edu-ID.
  • Store the "edu-ID" identifier in the organisation test account in the appropriate dedicated attribute.
  • Run the Affiliation AP client on the organisation test account.

For the Affiliation API operations, the organisation test account's swissEduPersonUniqueID value is used as key identifier, and the "edui-ID" identifier is used to specify the edu-ID account to link to.

Link regular accounts with the owners' edu-ID accounts in the production environment

This test may be used to verify if the synchronisation works in the production environment. The organisation can call its Affiliation API client for single, specific accounts having stored a production edu-ID identifier and check if synchronisation works as expected.

 

For organisations using Attribute Pull from organisation's Attribute Authority

Applies to Attribute Pull via the Attribute Provider API.

Test phase 1: Organisation tests its own implementation of the Attribute Provider API

Since it's the organisation's duty to implement and run the Attribute Provider API, you can do a lot of testing yourself.

You need to make sure that your implementation fulfils the requirements of the specification (available at Attribute Provider API).

You can use the test tool provided by the SWTICHaai Attribute Viewer to test your implementation. After having logged in with your AAI account, you can enter your API's URL and specify the required credentials. For getting more details, please see the instructions given there.

If you can't use or don't want to use this tool, you can also test your API implementation using curl. In this case, follow the instructions given below.

The following commands assume that your API instance is available at the base URL https://eduid-ap-api.uni-demo.ch/ap-api/.

  • Test if the list of affiliations (pairs of swissEdupersonUniqueID and swissEduID) can be retrieved.

    Example command:
    curl --user attribute-aggregator https://eduid-ap-api.uni-demo.ch/ap-api/affiliations
    (Adapt the command to match your deployment.)

  • Test if a single affiliation can be retrieved and all attributes are available as expected.

    Example command:
    curl --user attribute-aggregator https://eduid-ap-api.uni-demo.ch/ap-api/affiliations/123456@uni-demo.ch
    (Adapt the command to match your deployment.)

    Make sure that all attributes supported by your IdP (according to the declaration in the Resource Registry) are available, as well as the edu-ID identifier (attribute swissEduID).

Test phase 2: SWITCH runs tests against the organisation's implementation of the Attribute Provider API

SWITCH will do various test queries and verify if the data retrieved fulfils the requirements for synchronising affiliation data for yor organisation.