Migration 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:
- Attribute Exchange (synchronisation of affiliations between the organisation and the edu-ID)
- Linking Service Test (initial creation of an organizational affiliation for a person)
- AAI Login at edu-ID IdP (how the AAI login will work and look like after the migration)
The following sections describe the details.
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 university accounts with edu-ID test accounts (technical or personal accounts) in the test environment
Here we assume that the personal university 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.
Linking Service Test
Test organizational linking service
In this scenario the personal university account will be linked as affiliation with a test edu-ID account in the edu-ID test federation. It is assumed that the personal university account is in the organisation's directory.
Testing procedure:
- Set up a test linking service:
- the linking service is in the production intranet of the university (or test intranet if available)
- the linking service SP is in the test federation
- affiliations are created using the test affiliation API
- A person going through the linking service authenticates locally, and links the local account as affiliation to a test-eduID account
- check correctly created affiliation
- either programmatically using the affiliation API by executing an affiliation GET operation and verifing that all attributes are sent back,
- or interactively in the administration test portal https://test.eduid.ch/web/organisation-administrator/ , and verify the completeness of the previously added affiliation
The above procedure describes the creation of an affiliation. In a similar way, the update and removal of an affiliation can be tested by triggering the respective events in the organizational test identity management.
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 |
|
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 |
|
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:
- 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. - 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. - 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.)
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:
Suitable hosts file entries (for test cases requiring them):
- File on macOS/Linux:
/etc/hosts
- File on Windows:
C:\WINDOWS\system32\drivers\etc\hosts
# No entry is required for login.staging.eduid.ch, this domain name should be resolvable via DNS.
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