This article outlines the migration from an existing on-premises Shibboleth IdP to an AAF hosted Rapid IdP service. Each step outlines the activities and responsibilities of each group. This sequence connects a Rapid IdP instance to an authentication service, like AzureAD, Google Workspace or Okta. These Origin Identity Providers will require a configuration change to enable and trust the Rapid IdP service as an authentication endpoint.
The time to complete a migration depends on the time taken for each step. The AAF will perform most of the steps but requires the coordination of the customer’s technical staff to complete certain activities. Migration of both test and production services can be simultaneous, with the final cutover for each service occurring on approval.
Flowchart 1 provides an overview of the migration process.
The test identity provider is the first service to migrate. Migration of the production instance follows the same steps and includes any additional organisational change management protocols. The AAF must receive the Rapid IdP Product Subscription Form before production migration begins.
Rapid IdP Migration Steps
The following outlines the activities and the actors that will perform the step.
1. Upload IdP Configuration
The migration process begins on the successful upload of the test and/or production IdP configuration to the secure AAF storage service. The AAF will provide directions and a utility for this step. The customer’s IdP admin will perform the upload.
2. Review IdP Configuration
The AAF will review the uploaded configuration, identifying potential issues, non-standard setups and identifying all the customer’s bi-lateral services.
3. Discussion on Issues and Findings
The AAF and the customer will discuss any issues and non-standard configuration items and determine if the migration can continue.
A discussion of the bi-lateral services will determine those to include in the migration.
4. Setup IdP, Provide Test Plan and Tech Details
The AAF will perform the initial setup of the new Rapid IdP service. The AAF will provide the customer the following technical information;
- A Certificate CNAME record to be added to the customer’s DNS. The Certificate CNAME will enable the AAF to provision and maintain certificates for the TLS connection to the Rapid IdP service.
- The SAML 2.0 metadata to enable connection to the Origin Identity Provider.
- A list of attributes that Origin Identity Provider MUST provide to Rapid IdP service.
The AAF will provide a test plan that includes several pre-testing activities for the customer’s test audience.
5. Certificate CNAME and Origin Identity Provider Setup
The customer will:
add the Certificate CNAME to their DNS.
create a configuration in their Origin Identity Provider from the metadata the AAF provides.
ensure the necessary attributes are available within the Origin Identity Provider .
provide to the AAF the SAML 2.0 IdP metadata from Origin Identity Provider .
The following AAF guides are available for each of the following Origin Identity Providers:
The customer will provide basic branding information and graphics. The AAF will apply this branding to the Rapid IdP UI that the user may see from time to time. These pages include the login page, the attribute release consent page and any error and information pages.
6. Perform Pre-testing Activities
The customer will ensure their test audience completes the pre-test activities. In particular, the testers must capture a pre-migration attribute dump using the AAF Attribute validator (for Test: https://validator.test.aaf.edu.au; for Production: https://validator.aaf.edu.au).
7. Add Origin IdP Metadata to Rapid IdP
AAF will add the Origin Identity Provider metadata to Rapid Idp to enable the redirect of user authentication to the Origin Identity Provider.
8. Deploy Rapid IdP and Verify Setup
The AAF will verify the setup of the Rapid IdP service. On verification the AAF will deploy the new Rapid IdP instance into the federation.
Note: The customer’s existing on-premise IdP will remain active for all users until its Hostname CNAME DNS entry is updated. This update will occur in a later step (11).
9. Hostname CNAME details
The AAF will provide the Hostname CNAME details to the customer.
10. Validate Testing & Comparison with Pre-testing Results
Using the Hostname CNAME details, the customer’s IdP admins will verify the new Rapid IdP is functionally correct and all bilateral services are operational before hand over to the test audience.
All testers must temporarily update their local hosts file with the Hostname CNAME details to carry out testing activities. Updating the hosts file temporarily enables access to the new Rapid Idp service. Reverting the hosts file change reverts a tester to the on-premise IdP.
The customer should ensure the test audience completes the test plan and collects test results and compares with pre-testing results. Errors and issues at this stage will require investigation by the AAF.
This change will NOT impact non-test audience users.
11. Hostname CNAME active
When ready, the customer updates their DNS record with the Hostname CNAME details. On DNS update, the new Rapid IdP will become active. All users will now access the new Rapid Idp service as the DNS record propagates.
If any issues become apparent, reverting the Hostname CNAME in DNS will roll-back the service to the on-premise IdP.
A review of the migration and any issues resulting from the change will occur between the AAF and the customer. When ready, the customer will sign-off on the migration as complete.
Connect a Google Identity Provider to AAF's Rapid IdP Service: https://support.aaf.edu.au/en/support/solutions/articles/19000132304
AAF Test Validator Service: https://validator.test.aaf.edu.au
AAF Production Validator Service: https://validator.aaf.edu.au