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.

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.

{{snippet.Define identity services}}

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 Optional	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.

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.

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.

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	email
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	`isAuthenticatedSE` and `authenticateSE` service extensions are available to determine if a user is already authenticated and to control the authentication behavior.
Upstream Login	`loginSE` and `isLoggedInSE` used to determine if a request to an upstream application is authenticated and to be able to log in to an upstream app. Such situations are common when an app manages its own sessions or directly authenticates against a backing data store like LDAP or a relational database.
Load Attributes	`loadAttrsSE` customizes how the loading of attributes is done. 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.
Header Creation	`createHeaderSE` used to create a custom HTTP header. This extension is often used when an attribute needs to be enriched or concatenated with additional data.
Authorization	`isAuthorizedSE` used to override the default behavior that determines if a user is authorized. Note you cannot define both a rule and a Authorization service extension.
Handle Unauthorized	`handleUnauthorizedSE` can be used to override the default behavior when a policy evaluation denies access to the app.
Modify Request	`modifyRequestSE` can be used modify every HTTP request that passes through the app.
Modify Response	`modifyResponseSE` is an optional service extension that can be used to modify every response that passes through the app.

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.

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
1. Username: aadkins@strata-eval.io
2. 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.

User flows