Search…
⌃K

Maverics Hybrid Evaluation

Set up Hybrid Orchestrators and complete a Recipe that moves apps from Siteminder to Azure AD.

About this guide

This guide describes the steps to sign up for a Maverics Identity Orchestration Cloud account, download and install the Maverics Hybrid Orchestrator software, and configure an App Modernization Recipe using the Maverics Cloud Platform user interface.
If you have the prerequisites handy and have some proficiency with Linux, this tutorial will take you about 10 minutes to complete. If you are stuck and need assistance, contact the Strata Product Team.

System Requirements

Your Hybrid Orchestrator instance can be run on any Linux server or VM, on-premises or in a public cloud infrastructure provider such as Azure, AWS, or GCP.
  • Linux: RHEL 7.7 or greater, CentOS 7 with the zip package installed
  • No existing Maverics Orchestrator installation or configuration (will be overwritten)
  • Deployed in a non-production or sandbox environment.
  • Disk: 10GB (minimum)
  • Memory: 8GB (minimum)
  • Access to the following ports:
    • 22 (SSH/SCP)
    • 8080 (HTTP - Orchestrator)
    • 8987 (optional - Sonar demo app)
    • 8988 (optional - Canary Bank demo app)
  • Root or Administrator access (for installation and configuration)
  • Maverics Identity Orchestrator runs as user maverics under systemd (Linux)

Identity Prerequisites

  • Google Account: A Google account is required to create a Maverics Cloud Platform account. After signing up, Google will pass basic information to Strata to set up your account. Subsequent logins to your Strata account will use Google as a social login provider.
  • Identity Provider (IdP): A Microsoft Azure Active Directory or Okta account with a tenant configured as an identity provider. You’ll use the identity provider to authenticate users before accessing your application.
  • IdP Admin Details: A user configured with the appropriate privileges to either create or access the configuration information from your Identity Provider that is connected to your Maverics Orchestrator.
    • In Azure Active Directory, this is the information from your App Registration or Enterprise Application.
    • In Okta, this is the configuration of your Application.
  • LDAP server (optional): The recipe you will complete includes retrieving user attributes from an LDAP directory. You will need the host and connection details to that LDAP server so the Orchestrator can query it for the attributes. Don’t worry if you don’t have a LDAP server handy; you can do the entire recipe using attributes sourced from claims you get back from one of the IdPs listed above.
  • Upstream application: The application proxied by Maverics Orchestrator. Bring your own app or use public Strata test apps:
  • Transport Layer Security (TLS): A Private CA Root Certificate. If your application uses a TLS certificate signed by a private CA (e.g. apps hosted within a corprorate network) the Orchestrator requires this Root Certificate to securely communicate with the Upstream URL. This is not required for the test apps above.

Create a Maverics Cloud Platform account

Begin your Maverics Hybrid Orchestrator evaluation by signing up for an account with Strata.
  1. 1.
    From your browser, go to https://app.strata.io.
  2. 2.
    Click Sign up with Google.
  3. 3.
    Select your Google account or enter your Google email address.
  4. 4.
    Enter your First Name, Last Name, Company, Title, and Phone Number, then click Start Trial. This creates your Maverics account, your Orchestrator Registration Token, and begins your trial evaluation.
  5. 5.
    Download and install the Maverics Orchestrator.

Get a Hybrid Orchestrator via the UI

Download the Hybrid Orchestrator package and install the RPM with a single command.
Before you begin
For the purposes of this evaluation, Strata recommends installing the Maverics Orchestrator on a clean Linux machine running either RHEL 7.7+ or centOS 7 in a non-production environment.
  1. 1.
    From the Orchestrators page, click the Copy Icon to copy the bash command:
curl -s https://install.strata.io/install.sh | sudo bash -s -- {Registration_Token}
  1. 1.
    Paste the command into your Linux console and run it. The RPM package will be downloaded and unpacked, and the RPM will install with basic configuration to connect it to the Maverics Cloud Platform.
If you see the error: "unzip: command not found; Failed to unzip Maverics ZIP Package" install the zip utility ( sudo yum install zip) and re-run the installation script.
  1. 1.
    Tail the Orchestrator logs to check that the Orchestrator has started:
journalctl --identifier=maverics --follow
  1. 1.
    Verify connection to Maverics Cloud Platform. Check the logs for the following to verify the Orchestrator container is connected and registered with the Cloud Controller:
{"level":"info","msg":"Orchestrator registering with controller","ts":"2022-11-24T19:28:08.085063424Z"}
{"level":"info","msg":"Orchestrator registering with controller","ts":"2022-11-24T19:28:08.085063424Z"}
{"level":"info","msg":"Controller API Service registering with controller","ts":"2022-11-24T19:28:08.087559965Z"}
{"level":"debug","msg":"sending csr to controller at addr: https://controller-registration.strata.io/register","ts":"2022-11-24T19:28:09.365143674Z"}
{"level":"debug","msg":"successfully retrieved response from registration request","ts":"2022-11-24T19:28:09.591364216Z"}
{"level":"info","msg":"Controller API Service starting","ts":"2022-11-24T19:28:09.593905758Z"}

Troubleshooting

  • Maverics zip package fails to unpack: "bash: line 74: unzip: command not found; Failed to unzip Maverics ZIP Package"
    • To resolve, install a Zip/Unzip package on your Linux host. For RHEL, run:\ sudo yum install zip
  • If you make changes in the UI and do not see "Success" messages at the top of the screen, check the following:
    • Tail the Ochestrator logs if you haven't already done so: journalct1 --identifier=maverics -- follow
    • If the debug mode is disabled, you may not see INFO level logs from Orchestrator.
    • If you are running Orchestrator in debug mode, you may see the following DEBUG level logs:
      {"level":"debug","method":"PATCH","ts":"2022-12-16T01:20:41.668322131Z","url":"/tenants/0/controllerconn","user-agent":"Go-http-client/1.1"}
      {"level":"debug","msg":"received ControllerConn update request","ts":"2022-12-16T01:20:41.669613297Z"}
      {"level":"debug","msg":"successfully updated 'nextConnTime'","nextConnTime":"2022-12-16 01:21:11.649999928 +0000 UTC","ts":"2022-12-16T01:20:41.669833089Z"}
    • Workaround: Restart Orchestrator.
      1. 1.
        From your Linux console, run: sudo systemct1 restart maverics.
      2. 2.
        Log back in to the UI and make edits to your app gateway, provider, policy, etc. and click Save.
      3. 3.
        Check the Orchestrator logs.If the Orchestrator and Controller functioning properly, you should see: {"level":"info","msg":"successfully instantiated app gateway

Set TLS certs

To connect to Maverics Orchestrator securely with your browser, TLS certificates need to be set up manually to enable an HTTPS connection. The Orchestrator can be reached over HTTP if TLS certificates are not set, but some browsers will prevent access over insecure protocols by default. To set the TLS certificate and key, edit the maverics.yaml as described in the Transport Security (TLS) section.
  1. 1.
    Log in to your Linux VM and edit the /etc/maverics/maverics.yaml file as superuser:
    tls:
    maverics:
    # The certFile and keyFile represent paths to a PEM encoded public/private key pair.
    certFile: "/etc/maverics/cert.pem"
    keyFile: "/etc/maverics/key.pem"
    caFile: "/etc/maverics/rootCA.pem"

Configuring Recipe: SiteMinder to Azure or Okta

Modernize your application from a legacy authentication system to a modern IdP. Configure this recipe to replace SiteMinder with Azure Active Directory or Okta without refactoring your application code.
The outcome of this recipe enforces Azure / Okta as your identity provider across all of your applications.
To begin, select the application to modernize. For this recipe, we will use the Strata demo app (https://sonar.stratademo.io/), which uses several headers for authentication, including email, firstname, lastname , SM_USER, OAM_REMOTE_USER, and REMOTE_USER to indicate the user has been authenticated.
You can use your own app instead, or stand up the Sonar app locally as a container. For details, refer to the Sonar and Canary Evaluation Guide.
If you choose your own application, you will need to know which headers that application expects to consume so that it knows the user has been authenticated. In the case of apps that were previously integrated with SiteMinder, this is typically a header called SM_USER.
In our example, the Sonar app has traditionally been protected using SiteMinder for authentication, session management, and personalization. During this exercise we will move the authentication and session management to use an Azure Active Directory or Okta tenant. We will not cover any SiteMinder configuration or login and instead focus on modernizing app authentication through a hybrid Maverics Orchestrator and Strata’s cloud.

Add an Identity Provider

Add the identity providers you will use in your policy. First add your IdPs, such as Azure or Okta, then add an LDAP Attribute Provider (optional).

Add Azure AD SAML

Add Azure AD SAML as a Provider for authentication and as a source for attributes for headers and authorization.
  1. 1.
    From the left-nav, click Providers.
  2. 2.
    Click Create New Provider, then click Azure AD SAML.
  3. 3.
    Configure your Azure AD SAML provider with the following:
    • Name: A friendly name for your Provider. For this example, let’s use Sonar Azure SAML.
    • App Federation Metadata URL: The App Federation Metadata URL is used to retrieve the certificate required to verify the signature. When the Orchestrator is configured to use SAML authentication, Azure AD can be configured to sign the SAML Response, the SAML Assertion, or both. The SAML Metadata URL is used to retrieve the certificate required to verify the signature. You can obtain the App Federation Metadata URL from Azure instance > Enterprise Application > SAML-based Sign-On > SAML Certificates.
    • Reply URL (Assertion Consumer Service URL): This endpoint will be created by the proxy and must match a Reply URL for your Enterprise Application. The URL must include the App Gateway Host Name (https://app.example.com/acs). For this example, let’s use https://localhost/sonar/acs
      • Reply URL must match the Orchestrator hostname (if configured).
    • Logout URL: The URL to which Azure AD will callback once logout is successful. You can obtain the Logout URL from Azure instance > Enterprise Application > SAML-based Sign-On > Basic SAML Configuration.
    • Identifier (Entity ID): The unique identifier for your Azure Enterprise Application. You can obtain the Entity ID from Azure instance > Enterprise Application > SAML-based Sign-On > Basic SAML Configuration.
  4. 4.
    Click Add Provider.

Add Okta

Add Okta as a OIDC-based Provider for authentication and as a source for attributes for headers and authorization.
  1. 1.
    From the left-nav, click Providers.
  2. 2.
    Click Create New Provider, then click Okta.
  3. 3.
    Configure your Okta provider with the following:
    • Name: The friendly name of your Okta provider. (e.g. okta-example)
    • OIDC Well-Known URL: The URL that returns OpenID Connect metadata about the Okta authorization server. (e.g., https://example.okta.com/.well-known/openid-configuration).
    • OAuth Client ID: The client ID of the Maverics application registered in the Okta organization (e.g., <okta-client-id>).
    • OAuth Client Secret: The client secret of the Maverics application registered in the Okta organization. (e.g., <okta-client-secret>)
    • OAuth Redirect URL: The URL that Okta will use to redirect the client back to after authentication. The Maverics OIDC handler will be served on this URL. It should not conflict with the path of any application resources and can be arbitrary, for example /maverics-oidc or /oidc-handler. (e.g., https://example.okta.com/oidc-handler)
    • Click Add Provider.
  4. 4.
    Click Add Provider.

Add an LDAP Attribute Provider (Optional)

Configure user attributes from an enterprise LDAP directory service to add HTTP headers consumed by on-premises applications, or satisfying authorization conditions.
  1. 1.
    From the left-nav, click Providers.
  2. 2.
    Click Create New Provider then click LDAP Directory Service.
  3. 3.
    Configure the following:
    • Name: enter a name for your LDAP service, such as ldap-example
    • URL: The URL(s) of the LDAP server that Maverics connects with. Both a single URL and a list of URLs are supported. When multiple URLs are provided, a round-robin load balancing scheme will be used to distribute traffic (e.g. ldap://node1.ldap.com, ldap://node2.ldap.com).
    • Service Account User Name: The username used to connect to the LDAP server (e.g. uid=admin,ou=Admins,o=Example,c=US).
    • Service Account Password: The password used to connect to the LDAP server.
    • BaseDN: Specifies the location in which to perform the LDAP search (e.g. ou=People,o=Example,c=US).
    • Attribute Delimiter (optional): The delimiter used to separate multi-valued attributes. This is an optional field and is only necessary if an attribute is multi-valued. If no value is provided, a default of "," will be used for the delimiter (e.g. ^).
  4. 4.
    Under Create a User Attribute Mapping, complete the following:
    • LDAP Search Key: Provide the attribute you want to use for looking up user and group data. (e.g., uid). For this example, let’s use mail.
    • Provider: from the drop-down menu, select a provider. For this example, select the Azure provider you previously created.
    • Value: enter the value of the specified header. For headers from Sonar, you can use name.
  5. 5.
    Click Add Provider.

Add Headers

Headers define authentication policy for locations (paths) or applications in your App Gateways.
The Maverics Orchestrator can proxy upstream applications that require an external identity provider to authenticate the user and set values in HTTP headers before allowing user access.
We will create two headers to use as part of our modernization, one for a SiteMinder header from the Sonar demo app, and one for headers from an LDAP attribute provider.

Add a SiteMinder header

  1. 1.
    From the left-nav, click Headers.
  2. 2.
    Click Create New Headers.
  3. 3.
    Under Config Mapping, configure the following:
    • Header name: Since we are migrating off of SiteMinder in this example, our header name will be SM_USER.
    • Namespace: select the Provider for the header. In this example, let’s use Sonar Azure SAML.
    • Value: enter the user attribute value to verify the header. In this example, let’s use email.
  4. 4.
    Click Add Headers.

Add a header from LDAP

  1. 1.
    From the left-nav, click Headers.
  2. 2.
    Click Create New Headers.
  3. 3.
    Under Config Mapping, configure the following:
    • Header name: enter the name of your LDAP header. In this example,let’s use azure_mobile.
    • Namespace: select the LDAP Attribute Provider for the header. In this example, let’s use ldap-example.
    • Value: enter the user attribute value to verify the header. In this example, let’s use mobile.
  4. 4.
    Click Add Headers.

Create a Policy

Orchestrators use policies of one or more App Gateways to define and control access to applications. Policies determine what conditions must be met for a request to succeed.
For the purposes of this evaluation, we will need two policies: Unauthenticated and Authenticated. Complete the following task to create one policy, then repeat it to create the other.

Create an Unauthenticated Policy

Create an unauthenticated, unauthorized policy that will allow all users to access your app. Completing this task will result in Maverics Orchestrator proxying your application.
  1. 1.
    From the left-nav, click Policies.
  2. 2.
    Click Create New Policy.
  3. 3.
    From the Configure Policy page, set the following:
    • Policy Name: enter a name for the policy, such as Allow All.
    • Location enter the location (path) for this policy relative to your application. For the Unauthenticated policy, let’s use ‘/’ as the location, which will apply the policy to all resources in my app.
  4. 4.
    Under Authentication,select Allow Unauthenticated.
  5. 5.
    Under Authorization, select Allow All Access.
  6. 6.
    Under Location Headers, click Create New Headers.
  7. 7.
    Click Add Policy.

Create an Authenticated Policy

Create an authenticated policy that will enforce authentication to your app (or a resource on your app) with an IdP (Azure or Okta). You can also configure authorization for specific users via Headers or Claims. In this example, we will only set headers.
Completing this task will result in Maverics Orchestrator enforcing Azure/Okta authentication to the Executive Reports page of the Sonar demo app.
  1. 1.
    From the left-nav, click Policies.
  2. 2.
    Click Create New Policy.
  3. 3.
    From the Configure Policy page, set the following:
    • Policy Name: enter a name for the policy, such as Sonar Azure.
    • Location enter the location (path) for this policy relative to your application. For the Authenticated policy, let’s use /reports to only allow users with Azure credentials to access that resource.
  4. 4.
    Under Authentication, click Add Existing Provider, then select Azure AD SAML or Okta.
  5. 5.
    Under Authorization, select Allow All Access.
  6. 6.
    Under Location Headers, click Add Existing Header.
  7. 7.
    Select SM_USER.
  8. 8.
    Click Add Existing Header again and select ldap-example.
  9. 9.
    Click Add Policy.

Create an App Gateway

An Application Gateway sets the user access rules for your applications. The App Gateway defines a proxy configuration with authentication providers, user attributes, access policies, and routing information to create protective gateways for the target (upstream) applications.
There are three tasks required to create an App Gateway: Details, Policy, and Headers.

App Gateway Details

Configure the name, base path, and upstream URL for your App Gateway. Optionally, you can also configure a hostname, error and unauthorized pages, and a Root CA certificate.
  1. 1.
    From the left-nav, click App Gateways.
  2. 2.
    Click Create App Gateway.
  3. 3.
    Configure the following:
    • App Gateway Name: A friendly name for your App Gateway (up to 50 characters). Enter a name that relates to your chosen application. For this example, let's use_ Sonar Azure_.
    • Base Path: This is the path on the target application being exposed by the proxy. This is typically set to / to expose all paths, but you can specify a particular path on the Upstream URL to expose a single resource. For example, expose only https://server.com/users/ on an App Gateway proxied onhttps://www.example.com/, set /users/ as the Base path. The App Gateway will expose https://www.example.com/users/ without exposing any adjacent paths. For this example, let’s use **_/_**
    • Upstream URL: The URL of the target application. It must be accessible over the public internet but can be secured with a TLS configuration and IP filtering to prevent side-channel access if the URL serves the application with a TLS certificate signed by a private CA. For this example, let’s use https://sonar.stratademo.io/
    • Host Name (optional): A hostname or fully qualified domain name the App Gateway is listening for. Use this to differentiate between named App Gateways that behave differently depending on the hostname in the HTTP request (i.e. if the Orchestrator receives requests on multiple virtual hostnames). For this example, we will leave the Host Name field blank and proxy the Sonar demo app using localhost.
    • Unauthorized Page (optional): The URL your users are redirected to when a policy evaluation prevents access to the application (https://example.com/unauthorized, https://example.com/403). For this example, let’s use https://sonar.stratademo.io/accessdenied
    • Error Page (optional): The URL your user is directed to when an error condition occurs (https://example.com/error). For this example, let’s use https://sonar.stratademo.io/error
    • Select or add a Root CA certificate (optional): For the Sonar App used in this example, we do not need to add a Root CA.
      Transport Layer Security (TLS) protects and encrypts communications between clients and servers on the internet. The App Gateway proxy is exposed over HTTPS with a TLS certificate generated by the platform, but the target application will likely also be served with a TLS certificate. Suppose the protected application uses TLS certificates signed by an internal (private) CA. In that case, the App Gateway needs a copy of the PEM-encoded root CA certificate to connect to the Upstream URL securely. If the Upstream URL serves the protected application with a TLS certificate from a well-known public certificate authority (public CA), no additional TLS configuration is necessary.
      • To add a root CA, from the dropdown menu, select Add a Root CA.
      • Specify a name for your certificate and paste in the root CA (including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines).
      • Click Add Root CA Certificate.
  4. 4.
    Click Save.
  5. 5.
    Click Next: Policies.
Try it!
At this stage you should be able to confirm that your demo app is being proxied by the Maverics Orchestrator.
  • In your browser, go to https://localhost:8080. If you are connecting remotely to a VM on a private subnet, you must open a VPN tunnel and connect using the IP address of the VM instance (e.g. https://192.0.2.10:8080)
  • Log in to Sonar with user: jdoe; password: password

App Gateway Policies

Set the authentication and authorization rules for locations (paths) in your App Gateways.
  1. 1.
    From the Policies page, click the Policy drop-down menu and select your Unauthenticated policy, for example Allow All.
  2. 2.
    Click the Policy drop-down menu and select your Authenticated policy (Azure/Okta).
  3. 3.
    Once you’ve added policies, click Headers.

App Gateway Headers

Configure headers for your App Gateway that will authorize additional user attributes.
  1. 1.
    From the Headers page, click Add Existing Header.
  2. 2.
    Select the SM_USER header.
  3. 3.
    Click Add Existing Header then select the ldap-example header.
  4. 4.
    Click Save.
  5. 5.
    Click Done.
Your App Gateway configuration gets deployed to the Maverics Orchestrator.
Try it!
At this stage you should be able to confirm that authentication to your demo app is being enforced by Azure or Okta via the Maverics Orchestrator.
  • In your browser, go to https://localhost:8080
  • Go to the protected resource in the app, such as /reports.
  • At the prompt, log in with your Azure or Okta credentials.

Next steps

Contact Strata Sales for more information on the Maverics Cloud Platform!