Overview
The Proxy Application Pattern deploys a Maverics Orchestrator in front of an application. The orchestrator acts as a reverse proxy, intercepting requests and enforcing authentication and access policies through orchestrated user flows. This allows legacy and modern apps to integrate with IDPs, enforce MFA, attribute providers or enable SSO without code changes.
.png?sv=2022-11-02&spr=https&st=2025-05-05T15%3A59%3A44Z&se=2025-05-05T16%3A19%3A44Z&sr=c&sp=r&sig=g7e0au1nXBXSd6%2BN%2BMcnmWUv3MdmySLyfpOFcETQj1A%3D)
Click to enlarge
This guide provides an overview of the following topics:
Prerequisites
Completed the Maverics Storage Configuration Guide
This guide provides a IDP, header app and test user credentials, or optionally you can bring your own:
Admin access to an IDP
Access to a header based application
Consider your proxy deployment architecture
The Maverics Identity Orchestrator is intended to address various identity challenges, allowing for deployment through different patterns to effectively tackle the specific issue at hand. Below are the most prevalent deployment architectures, and you can continue reading to discover the related advantages and disadvantages.
Central Pool - In this deployment model, a centralized pool of Orchestrator instances are used to protect applications. This model works well when a team is comfortable making network changes, and would prefer to not interface with application teams regularly.
Local Proxy - The local proxy pattern co-locates the Orchestrator on the same host as the application. This model works well for header-based apps, or for application teams that control the auth flow for their app.
RP-IDP - The RP-IDP architecture combines the “local proxy” model (relying parties) with a pool of Orchestrator(s) that act as an IDP. This pattern works particularly well for administrators who are moving off a legacy web access management solution such as SiteMinder or Oracle Access Manager, but can be used successfully for a variety of use cases.
Define services to include in your Identity Fabric
You can choose identity or attribute providers to include in your Identity Fabric. Leveraging services from cloud based IDPs such as Microsoft Entra ID, Okta, Auth0, and Ping, open source providers such as Keycloak or WS02, and on prem services like LDAP, ensures that your application has what it needs for a secure authentication and authorization user flow. For providers not on the list, Maverics supports generic SAML and OIDC connections.
From your IDP, you will need to register a new application. From Maverics, you will create a new identity fabric configuration. You can then use it in a user flow for authentication.
If you need to use another identity service like an LDAP directory, you can string them together with a username mapping, allowing you to use extended attributes for claims or authorization rules.
You can also use these providers in Service Extensions when building custom Authentication flows or dynamically loading or transforming attributes.
The following steps use the Strata provided Keycloak IDP:
Go to Identity Fabric
On the right, scroll and select Keycloak (OIDC)
Click to enlarge
For the OIDC configuration, enter the following:
.png?sv=2022-11-02&spr=https&st=2025-05-05T15%3A59%3A44Z&se=2025-05-05T16%3A19%3A44Z&sr=c&sp=r&sig=g7e0au1nXBXSd6%2BN%2BMcnmWUv3MdmySLyfpOFcETQj1A%3D)
Click to enlarge
Name | Description | Field |
---|---|---|
Name | A unique identifier for the connector configuration. This cannot be changed once it is set. | mavericsOIDC |
OIDC Well Known URL | The URL that returns OpenID Connect metadata about the OIDC authorization server. | https://keycloak.strata-eval.io/realms/maverics/.well-known/openid-configuration |
OAuth Client ID | The OAuth client ID registered with the OIDC provider. | mavericsclient |
OAuth Client Secret | The OAuth client secret associated with the client ID. | mavericsclientsecret |
Redirect URL(s) | A list of allowed redirect URIs for the login flow. | https://localhost:8443/oidc |
Logout Callback URL(s) | A list of allowed redirect URIs for the logout flow. | |
Scopes | A space-delimited string specifying the scopes to request during authentication. | openid profile email |
Proof Key for Code Exchange (PKCE) | Enable or disable Proof Key for Code Exchange (PKCE). | Enabled |
Configure your upstream application
From the Applications page, create a proxy app by selecting Proxied App under Application Types.
In the Proxy App Configuration Page, enter the following values to use the Strata provided application.
Click to enlarge
Field Name | Description | Value |
---|---|---|
Name | The friendly name of your application. | Canary Bank |
Upstream URL | The URL to determine where to send traffic after doing its work, like evaluating policies or sending users to a provider for authentication. | https://canarybank.strata-eval.io |
Route Patterns | The list of patterns that will be used to map a request to the appropriate app. Either a hostname, path, or combination of the two can be used. | / |
Skip TLS Verification | This should only be used for testing. When enabled, the HTTP client will not validate the server's certificate chain and host name. This should always be used with extreme caution. | Enabled |
Unauthorized Page | The URL your users are redirected to when a policy evaluation prevents access to the application. | /accessdenied |
Preserve Host | Used to determine if the host header should be preserved on outbound requests. By default, the orchestrator will set the host header to match the upstream's host. This field is often used when the orchestrator is forwarding traffic to another reverse proxy such as Apache. | Enabled |
Logout Callback URL | The endpoint that will be exposed to facilitate a logout for application users. | /logout |
Post Logout Redirect URL | The address where a user will be redirected after a successful logout. | https://canarybank.strata-eval.io |
Click Create to save the configuration.
Configure the locations to be used in user flow policies
After you've created the app configuration, you can specify resources by selecting the proxy app in the Applications list. Resources are locations in your app for which you will map to in your user flows when defining access policies and headers. Examples include a path to a resource such as /, or /example. You can also specify regular expressions. To apply regular expression matching to resource path, add "~ " (note the space) at the front of the resource location.
.png?sv=2022-11-02&spr=https&st=2025-05-05T15%3A59%3A44Z&se=2025-05-05T16%3A19%3A44Z&sr=c&sp=r&sig=g7e0au1nXBXSd6%2BN%2BMcnmWUv3MdmySLyfpOFcETQj1A%3D)
Click to enlarge
Add the following resources:
/
/accessdenied
/logout
Define the user flow for your upstream app
From main navigation, click User Flows, and click New. Enter a name for the user flow and select the application Canary-Bank. Click Create.
.png?sv=2022-11-02&spr=https&st=2025-05-05T15%3A59%3A44Z&se=2025-05-05T16%3A19%3A44Z&sr=c&sp=r&sig=g7e0au1nXBXSd6%2BN%2BMcnmWUv3MdmySLyfpOFcETQj1A%3D)
Click to enlarge
Access Control Policies
Defining access control policies enable you to enforce authentication and authorization policies for your upstream application. You will define an open policy for endpoint redirect behavior for logout and unauthorized access. For the root resource of the app, we will require authentication and an attribute-based authorization rule.
Create a open policy
Under Access Control Policies, select the
/accessdenied
resource and click Add.
.png?sv=2022-11-02&spr=https&st=2025-05-05T15%3A59%3A44Z&se=2025-05-05T16%3A19%3A44Z&sr=c&sp=r&sig=g7e0au1nXBXSd6%2BN%2BMcnmWUv3MdmySLyfpOFcETQj1A%3D)
Click to enlarge
For Authentication select Allow unauthenticated users
For Authorization, select Allow all access
Using the breadcrumb navigation in the title, select the user flow name.
Repeat these steps to add a open policy for the
/logout
resource.
Create a restricted policy
Under Access Control Policies, select the root
/
resource and click Add.For Authentication select the IDP Keycloak you created in the previous section.
For Authorization select Use rules to define access
Click to enlarge
To restrict access based on a user attribute for the Provider, select Keycloak, attribute email, equals, aadkins@strata-eval.io. Click Add rule.
This application requires specific headers for authorization and for display on the page. In the Headers section use the following values (to confirm click the green
✔️ ) :
Header | Provider | Value |
---|---|---|
SM_USER | Keycloak | |
firstname | Keycloak | given_name |
lastname | Keycloak | family_name |
Using attribute providers
Attribute providers supply additional identity context that may not be included in the initial authentication response from an IDP. These attributes can be critical for:
Claim enrichment - Add more detailed user information (like display name, employee ID, or entitlements) to pass downstream to applications.
Authorization decisions - E.g., use a department or role attribute to enforce policy-level access control.
Cross-provider attribute mapping - Normalize schemas across IDPs (e.g., map mail from LDAP to email expected by your cloud app)
Auditing and compliance - Pull consistent user attributes for audit trails, especially in regulated environments.
How to Use an Attribute Provider in a User Flow
Here’s how you’d integrate an attribute provider into your Maverics orchestration policy:
Configure the attribute source in Identity Fabric.
Depending on your architecture, choose one or more attribute sources that will provide user data to enrich authentication and enable authorization:
Microsoft Graph attribute provider - Ideal for cloud-native environments. Use this to fetch attributes like jobTitle, manager, department, or employeeId directly from Microsoft Entra ID. Configuration required: Microsoft Graph: Tenant ID, client ID/secret, scopes
Okta attribute provider - Useful for accessing custom user attributes, group membership, or application-specific profile data stored in Okta. Configuration required: Okta domain and API token
LDAP attribute provider (e.g., Active Directory) - Common in hybrid or on-prem environments. LDAP is a trusted source of employee directory data and attributes like cn, mail, or memberOf. Configuration required: Host, port, bind DN, credentials, and base search path
Load Attributes service extension - This extension is commonly used to load attributes from proprietary or custom data sources, such as internal databases or enterprise APIs that aren’t supported as standard attribute providers.
Create a username mapping between your IDP and your attribute provider. To retrieve user attributes from your attribute provider, you need map an attribute from the authenticated session (such as an email or username) to a unique identifier in the attribute provider (like mail, uid, or sAMAccountName) that can be used to look up the user.
Click to enlarge
Open your user flow, in the Attribute Providers section, select a configured Attribute Provider, next choose the identity provider that will be used to authenticate the user, and then choose the username mapping attribute to used to uniquely identify the user. Note: When using a Load Attributes service extension, the username mapping logic needs to be defined the GO module.
Use the attribute provider in your user flow.
Click to enlarge
Click to enlarge
Now that you have defined an attribute provider you can use it as a source of claims for your application or in a authorization rule.
Explore the service extension points
Several service extensions are available for use with proxy application patterns:
Feature | Description |
---|---|
Authentication |
|
Upstream Login |
|
Load Attributes |
|
Header Creation |
|
Authorization |
|
Handle Unauthorized |
|
Modify Request |
|
Modify Response |
|
Deploying the application
Deployments Overview
Deployments in Maverics are how you bundle and publish your orchestration configurations — including applications, user flows, identity services, and policy logic — to your orchestrators for enforcement. Before deploying, review theDeployment Overviewto understand how environments, services, and storage work together in Maverics.
Prerequisite: Storage Configuration connected to a Orchestrator service
To successfully deploy and test your application’s user flow, you must first configure a storage storage provider and connect it to installed orchestrator services.
Recommended: Use Maverics Storage for the fastest and simplest evaluation experience.
Other storage options (e.g.,AWS S3, Google Cloud Storage, Github repo, and Microsoft Azure Blob storage) are supported — see the full Storage Configuration Guides for setup instructions.
Add your application to a deployment
Once your storage is configured, you can deploy your application using the Deployment Manager:
Navigate to Deployments in the Maverics UI.
Create a new deployment or select an existing one.
Add your application(s) to the deployment:
Click Publish Preview to review and validate the deployment configuration.
After confirming the preview looks correct, click Publish to push the configuration to your orchestrators.
Configure global settings
Sessions and Cookies
The Session and Cookies settings enable you to configure how Maverics handles user sessions at runtime. These settings control session lifetime, idle timeout behavior, in-memory cache limits, and cookie properties used for maintaining session state. This includes the Session Lifetime and Idle Timeout service extension points. You can apply these settings globally to all applications within an deployment.
.png?sv=2022-11-02&spr=https&st=2025-05-05T15%3A59%3A44Z&se=2025-05-05T16%3A19%3A44Z&sr=c&sp=r&sig=g7e0au1nXBXSd6%2BN%2BMcnmWUv3MdmySLyfpOFcETQj1A%3D)
Click to enlarge
This configuration will trigger a session expiration after the user is idle for 30 minutes and after a maximum period of one hour. On session expiration, the user will be required to re-authenticate with the IDPs associated with the defined policy.
Single Logout (SLO)
The Single Logout Settings interface allows you to configure the global logout behavior for the applications in your deployment. This includes defining the endpoint clients use to initiate a logout, as well as optional settings for redirecting users and triggering custom logic after logout. You can also attach a Post Logout Service Extension to define custom behavior after a logout has occurred. Single Logout documentation.
HTTP Server
HTTP Server settings including the HTTP URL, port, TLS can be configured using a Orchestrator Host environment files.
Testing the runtime experience
In following configuration values in this guide you can use the Strata provided Canary Bank app and Keycloak IDP to test the runtime experience. If you are using an Evaluation Bundle that comes with the Maverics Storage configuration.
Follow the Maverics Storage guide and start up your orchestrator service.
Go to your Orchestrator URL https://localhost:8443/
You will be redirected to sign in with Keycloak. Enter the following credentials
Username: aadkins@strata-eval.io
Password: password
This will create a session with Keycloak, evaluate the authorization rules, and pass back in the headers to allow access to the app.