<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=58103&amp;fmt=gif">
Skip to content
All posts

Healthcare Platform Migrates Keycloak Instance In 2 Weeks

Client Overview

This company is a leading provider of integrated health and benefits management solutions, serving over 20 million individuals across thousands of organizations. 

The client manages digital health and benefits administration, providing a seamless platform that unifies health plan administration, wellness programs, and analytics. It is a critical partner for large employers managing complex healthcare needs.

Challenge

The client faced a legal request from another, larger company due to a branding issue. Unfortunately, changing the brand name meant updating the URL in their portal. While this seems trivial, there were deeper requirements and constraints for the business.

The client uses open-source Keycloak to manage logins, which provides a URL to identify the business. To comply with the legal request, they would need to update their single-sign-on URL to match the new branding. 

However, this also meant asking their entire partner company network to reconfigure their systems, causing major disruption for the partners and their customers. This was not only a new domain name but an entire URL path they needed to change based on the Keycloak realm.

The client’s team was capable. However, they did not have the time to rewrite hundreds of URLs and reconfigure hundreds of partner systems. 

They needed a better solution. 

The client knew Shadow-Soft had extensive experience with Keycloak and contacted us for help finding the smoothest solution within a month to comply with the legal requirements.

The Solution

We set up Keycloak as an intermediary of itself, setting up one realm representing the new URL while maintaining the old Keycloak realm. This allowed the business to seamlessly redirect users to the new branded URL without having to reconfigure 100s partner company portals and manage the disruption.

We set up an additional Keycloak server under the new branded name. Then, we turned off their ability to log in directly into this Keycloak system and enabled the new Keycloak provider to be the federated identity provider for the old Keycloak instance.

When someone logs in with their browser, they’re sent to the legacy Keycloak instance and are immediately redirected to the new instance, thereby mascarding the previously branded URL. 

Key Features

The client’s portal login is under the new branded URL in compliance with the legal requirements. 

Features:

  • The old URL does not show up when customers of client partners log into their portal.
  • No customer disruption for setting up the new configuration.
  • Tested and deployed new solutions within three weeks.

Our Process

We analyzed the existing setup and suggested three potential solutions based on their needs and our understanding of Keycloak for their environment. 

  1. Run a current state assessment of how they were using Keycloak:
    • Current protocol in use
    • Backend identity
    • Identity origin
    • Total usage of the platform
  2. Share results of the discovery:
    • Users would be migrated over to the newly created realm/s via SQL scripting.
    • Over time, partner applications (Keycloak clients) would be migrated to the new platform until the old system could be fully decommissioned.
    • Customers needed different options and support with any concerns.
    • Mobile application usage would require customizations on the server side to allow communication to continue without interruption.
  3. Present options for remedying the situation with potential concerns:
    • Option 1 - Additional Realm with Brokering:
      • Create an additional realm and a custom flow in each realm that brokers all the realms together. 
      • Users with an established session one realm can access client applications in both the old and the newer platform realm.
    • Option 2 - Rewrite Istio Ingress Rules:
      • Allow realm access from both URL patterns without alerting clients/users.
      • Move all users currently and clients back to the original realm. 
      • Use Istio rewrite rules to handle new and old incoming URLs to get them to the realm.
    • Option 3 - Broker authentication between current realms:
      • Migrate users to the new realm. Add old realm as a client to the platform realm, ensuring client mappers are configured for each forwarded attribute. 
      • Register platform realm as a Keycloak OIDC IDP using client secret, ensuring identity mappers are configured for each attribute. 
      • Update the existing flow to use the new identity provider set as an “alternative.” 
      • Update partner applications client configurations in the original realmto perform authentication in the new platform realm using updated authentication flows.
  4. Show the client diagrams, mapping out each solution.
  5. Recommend the best solution based on our experience with Keycloak.
  6. Run Validation Testing to show a working solution.
  7. Provide the option of implementation support for rapid deployment.

Roadblocks

After showing the client the solution, they still had trouble visualizing what was needed for implementation, and they doubted how effective the solution would be. 

We illustrated how to implement the solution through demonstrations with small use cases in the client’s demo environment, helping them troubleshoot their team's challenges until they understood how to set it up and why each potential solution could work. 

With that understanding, they decided on the most seamless solution to integrate that would meet their current requirements, implemented the changes and reconfigured their systems within two weeks.

After the new environment was fully setup, the team began performing database manipulation scripts and migrated the data over. They also did SQL dumps and paired them with the new database. 

This prevented them from having to manually recreate the usernames with the same encrypted passwords inside of the new realm.

Tools

The client used Keycloak as an identity provider. We showed them how to use the brokering function of the Keycloak to deploy the solution.

KEYCLOAK

Results

The project was completed within two weeks, delivering an effective solution that worked completely in a faster timeline than the client expected. This helped them avoid the legal roadblocks a delay in implementation would have created.  

What’s Next

After delivering the guidance the team needed to knock out the project within the pressing deadline, they will conduct a systems assessment with Shadow-Soft.