Introduction
To continue from where we left off, the technical challenges involved in embedding what we refer to as a “legacy application” were not as bad as we feared, though by the same token, the process was not as smooth as we hoped.
Modifying the App Configuration
The first step was modifying the app configuration, which amounts to setting the ‘frame-src’ and ‘frame-ancestors’ in the Content Security Policy to allow embedding only from our Curator site. Pretty straightforward in an Nginx application once you get access.
Initial Embedding Attempt
For kicks, we embedded the entire app in a single iFrame and got the OAuth login screen as expected, followed by a swift permission denied from “login.microsoft.com.” Some of you may be nodding at this point because you know that Microsoft does not allow any sort of auth request to originate from an iFrame, and nor should it. It did present something of a problem considering the client wanted the web app to be independently accessible and secure.
SAML Authentication Integration
Curator itself has built-in support for SAML authentication workflows, and Power BI and the client were set up to use SAML, so it seemed natural that we could adapt the web app to use SAML as well. With everything under the same hood, we had hoped the SSO from the Curator login would extend to the application and since they wouldn’t be prompted to log in, all would be well.
Dealing with Outdated Dependencies
The shadow hanging over any implementation was, of course, the mountain of outdated dependencies involved with the application. But thankfully, the web app was using Docker, and the existing OAuth proxy was being run in its own container, so all we had to do was swap out that container for a custom SAML proxy that served up the same information. Node Express and SAML-Passport made this fairly straightforward to set up, and we had SAML authentication protecting the web app itself.
Resolving Permission Issues
Back to Curator though, and what do we find? Permission denied, of course! As it turns out, having multiple applications authorized with SSO through the same IDP will indeed allow a single sign-on for the user, but in the background, each application still sends out a request regardless of status, and that check remains disallowed from within an iFrame.
Alternate Authorization Path
The solution was to have an alternate authorization path, which was provided by Curator’s REST API (and their awesome support staff!). In the case where the web app was being run within an iFrame, the SAML proxy container would reach out to Curator instead of Microsoft to obtain identity. In effect, this put the embedded app under the umbrella of Curator SAML and removed that permission-denied issue. As Azure Active Directory was the identity provider for each component we had a consistent security backplane for the solution. And voila, web app pages were rendered properly and securely within Curator iFrames.
Looking Ahead
We’ve made significant progress in integrating the legacy web application with Curator, overcoming initial technical challenges and ensuring secure and seamless access through SAML authentication. But our journey doesn’t end here. In the next and final installment of our Curator Implementation series, we will dive into the customizations that were crucial to meeting our client’s unique needs. From JavaScript tweaks to role-based access control and UI enhancements, we’ll reveal how we tailored Curator to deliver a truly personalized and efficient user experience. Stay tuned for more insights and the final touches that made this project a resounding success!
