The Maverics Identity Orchestration Express Demo

With Strata’s Maverics Identity Orchestrator™, you can migrate and modernize your identity systems without painful application rewrites. You’ll save hundreds of hours, and millions of dollars on your upcoming project.

In the spirit of transparency, we think it’s more important to show you how we do things than tell you about it. In this 10-minute express demo, we’ll show you how to use Maverics Identity Orchestrator™ to migrate an app from OAM to Azure AD. Don’t worry about which systems we’re showing in this demo, Maverics is flexible and works with any legacy or modern identity system and directory.

In this demo you’ll see:

  • Just-in-time user migration from a legacy identity system to the new identity system
  • Maverics perform the session abstraction to manage access to the protected legacy application
  • Dynamic access policy capabilities via Maverics’ service extensions
  • App run seamlessly after the legacy system was decommissioned
  • Unchanged user experience and the app completely unchanged as well

Video Transcript

Welcome to the Strata demo. I’m James and I will be showing you how you can use Strata’s Maverics software to automate the modernization of legacy identity systems – without rewriting your apps.

In this demo, we’ll use Maverics to migrate an app from OAM to Azure AD. That said, don’t worry about which systems we’re using—Maverics is flexible and works with any legacy or modern identity system and directory. Whether you need to migrate from Oracle or CA SiteMinder or RSA ClearTrust, Maverics can help. And if you want to move to Azure Active Directory, Okta or some other modern identity system, Maverics can help.

  • Strata has a unique distributed approach to identity management that we call an Identity Fabric. The most important things to know about an identity fabric are that:
  • You can orchestrate consistent identities and policies across different identity systems from one place by using an abstraction layer driven by a simple declarative API.
  • You can externalize on-premises app access to cloud-based users with a hybrid, zero-trust model that unifies identity across data centers and cloudsAnd you can automate the migration of users from legacy identity systems to modern cloud identity systems – all the while your end-user experience is uninterrupted.

We’ll be focusing primarily on the modernization and migration use case today, stay tuned for demos of the other use cases.

Last thing before we get into the demo: let’s review common legacy architecture and the challenges we all face in our current state.

On the left, you have a legacy infrastructure and identity system with existing user profile and access policy information. On the right, you have a modern cloud service provider and new identity system. When automating application migrations, you need to do three main things:
one, automate the user identity migration process from the old to the new;
two, leverage the new identity systems authentication and access capabilities;
and three, migrate the legacy application without rewriting it, without disrupting the user experience.

On the right, you can see that Maverics allows you to perform identity orchestration through the configuration of simple App Gateways and Migration Gateways, which automates the
identity and access policy synchronization process. Maverics also provides session abstraction capabilities that enable you to leverage the new identity systems’ authentication providers using a range of session types including SAML, OIDC, headers and more. As a result, Maverics is a faster, more flexible, and cost-effective way to migrate your apps.

Okay, let’s get started with the demo. What you have here is the Legacy Identity System, Oracle Access Manager often known as O-A-M. Within Oracle Access Manager, we have an application domain called pd-demo. This application domain contains our Sonar application that includes several protected resources including, dashboard, cost centers, projects, and reports.

I want to highlight the authorization policies for this application. If you go to the responses, you’ll see that we’re setting the last name and first name as part of header responses so that the application can welcome the user. We’re extracting and retrieving the names from the currently integrated OAM directory.

Here, you have the modern identity system, Azure AD. Notice we have some default users here, but we are missing one important user, and that’s our demo user for today—named Allan Adkins. The very first use case we’re going to demonstrate is the automated identity migration from OAM to Azure AD using our migration orchestration flow.

What you just saw here is a login request for the Sonar Systems application. Maverics has determined that the user hasn’t been migrated yet and therefore directed the authentication to Oracle Access Manager to verify who the user is.

Next, let’s go ahead and log in as Allan Adkins….and authenticate. Once I authenticate, Maverics will know who the user is. Behind the scenes, Maverics runs the migration gateway— I’ll show you what that looks like when we review the YAML configuration. The migration gateway automatically migrates the user into the Azure AD tenant. Let’s take a look at Azure A-D now…and you see that Allan Adkins has been migrated in a just-in-time fashion from OAM to Azure AD.

Now that I’ve migrated the user has to Azure AD, we will show Maveric’s session abstraction. Session abstraction is what allows you to delegate the authentication into Azure AD. In essence, it lets you authenticate through Maverics and then have that session passed to your app using what’s known as “ last-mile” integration. Session abstraction can also send header-based information and attributes to the application. Shortly, you will see the user being orchestrated by Maverics into the Sonar Systems application, the application will receive the user and display the user’s first name and last name.

Let’s go ahead and show the session abstraction now…And there you have it, the Orchestrator said, “Oh, I see that Allan Adkins has been migrated to Azure AD, therefore, I’m going to direct the user’s authentication to use Azure AD to authenticate the user.” So let’s go ahead and authenticate as Allan Adkins….And there you go, the user seamlessly accesses the app using the Maverics App Gateway. You can see that I’m welcomed into the application as Allan Adkins. More to come on the App Gateway later when we review the Maverics configuration.

Next, let’s take a behind-the-scenes look at how this is configured. What you see here is the Orchestrator’s configuration. Maverics uses an easy to configure YAML- based model that is very similar to Kubernetes. The configuration that I want to highlight is the OAM to Azure AD migration

Migration Gateway: the first configuration I’d like to highlight is the OAM to Azure AD migration gateway. Maverics uses a declarative model to define that when the user attempts to access the Sonar app, migrate her from the source – OAM – to the target – Azure AD. The migration gateway declares that the OAM LDAP connector should be used as the attribute provider that supplies the user profile attributes needed to create a valid user in Azure AD. The migration gateway makes is easy to map these attributes across the completely different schemas – or namespaces – of these two identity systems. It’s that simple!

Now, I’d like to highlight App Gateways. App Gateways are the way that the Maverics performs the last mile integration into the application, in this case, Sonar Systems. A few important things to highlight about the App Gateway.

First, App Gateways allow you to define one or mor IDPs to be your authentication and session provider. This is important for enforcing policies where you use one IDP for authentication and a second IDP for, say, a multi-factor challenge.

Second, you may have one or many attribute providers. This is important if you want to add more attributes than you can get back in a claim from your authenticating IDP.

Third, as you can see here, the App Gateway allows you to easily configure any header or header name and determine where the header value is coming from. In this example the app gateway gets it’s attributes from the claims returned by Azure AD after authenticating the user. It’s not unusual to add additional attributes, such as a group membership, from another enterprise directory or database.

Maverics supports name spacing, so you can say Azure.family_name, in this case, for last name and you can say for first name, and for this other header OAM_REMOTE_USER, you can say azure.sub – meaning the ID of the authenticated user. If you had multiple providers here, you can easily reference the provider and then reference the attribute name to pass into any header you’d like to configure.

Finally, the App Gateway supports a range of policies—from very simple to highly complex policies. This policy example here is very simple. It’s defining the root resource and all the resources under the root, and then instructing Maverics to allow any user authenticated by Azure AD to access that application—in our case, the Sonar Systems Application.

Now comes the fun part. Time for Maverics to decommission (or sunset) Oracle Access Manager. So what we’re going to do is we’re going to log into the admin console here in the live system. You see that the server is in an OK health status, and it’s running. We’re going to shut down Oracle Access Manager because we don’t need it anymore. We click, force shutdown now, then click on yes, and you can see FORCE SUSPENDING—it’s shutting down the server…and now the state is in a shutdown state, which means the server itself is not reachable which is a good way to show how things behave once OAM is gone.

Now, we’re going to see how Maverics uses the abstraction layer once more, this time accessing Sonar Systems leveraging an App Gateway using Azure Active Directory without OAM in the picture. As you can see, Maverics is delegating the authentication request to Azure AD. Allan Adkins is able to log in to the Sonar Systems, even though Oracle Access Manager has been decommissioned.

Now, let’s review what we just demonstrated… First, you saw a just-in-time user migration from a legacy identity system to the new identity system. You saw Maverics perform the session abstraction to manage access to the protected legacy application. Then you saw the dynamic access policy capabilities via Maverics’ service extensions. And finally, you saw app run seamlessly after the legacy system was decommissioned. As you saw, the user experience is unchanged and the app was completely unchanged as well.

That concludes today’s demo. Please reach out to us with questions at [email protected] or sign up to get a personalized demo on Ask about Strata’s Express, 3-day Proof of Concept option to see Maverics work in your environment with your apps.

We at Strata look forward to helping you modernize your identity infrastructure and move to the future of multi-cloud. Thank you.