This article outlines the migration from an existing on-premises Shibboleth IdP to an AAF hosted Rapid IdP service and integration with an authentication service, like AzureAD, Google Workspace or Okta. These services are Source or Origin Identity Providers and require a configuration change to enable and trust the Rapid IdP service. Each step outlines the activities and responsibilities of each group. 


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.
  • Values for the following configuration items:
    • the Single Sign On URL or Reply URI - also known as ACS (Assertion Consumer Service)
    • an Audience URI or Identifier (Entity ID) URI - which exactly matches the Shibboleth IdP EntityID if migrating an existing service
  • The SAML 2 metadata to enable connection to the Origin Identity Provider
  • a SAML certificate for signing assertions
  • A list of SAML attribute names that Origin Identity Provider MUST provide to the Rapid IdP service - attribute names are case-sensitive.


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 configuration values and metadata the AAF provides

  • ensure the necessary attributes are available within the Origin Identity Provider

  • provide to the AAF the SAML 2 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). The pre and post-migration attribute dumps should be compared to ensure no change in the key attributes released during the migration. 


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 (Production or Test). 


The customer’s existing on-premise IdP will remain active for all users until the 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. Changes to a local computer's hosts file requires elevated privileges on the tester's local computer.


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

At Go-Live time, the customer updates their DNS record with the Hostname CNAME details. When the DNS update becomes active, the new Rapid IdP will become active. All users will now access the new Rapid IdP service as the DNS update propagates to DNS servers.


If any issues become apparent, reverting the Hostname CNAME change in DNS will roll-back the service to the on-premise IdP. It is important to set the TTL of the CNAME record to 5 minutes at least 24 hours before Go-Live to ensure the short TTL has sufficient time to propagate.


12. Sign-off

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. 


Links

Connect an Origin Identity Provider to AAF's Rapid IdP Service:

Google https://support.aaf.edu.au/en/support/solutions/articles/19000132304

Azure AD https://support.aaf.edu.au/en/support/solutions/articles/19000138052

Okta https://support.aaf.edu.au/support/solutions/articles/19000136594

AAF Test Validator Service: https://validator.test.aaf.edu.au

AAF Production Validator Service: https://validator.aaf.edu.au