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