Applications

User Flows Identity Fabric Service Extensions

Applications represent how a specific app or service is integrated into your identity infrastructure. Each application is based on a common integration pattern—like OIDC, SAML, legacy proxy, or API endpoints—which defines how it communicates and behaves at the protocol level. These patterns are linked to User Flows, which control the logic for authentication and authorization. User Flows can also include optional Service Extensions that add custom functionality such as claim transformations, third-party API calls, or extra security checks.

User Flows rely on components from the Identity Fabric, such as identity providers (IDPs) and attribute providers, to handle authentication and provide the necessary user data for each application.

Applications are also connected to Provider settings, which determine how the orchestrator behaves at runtime—for example, as a proxy, a SAML Identity Provider, or an OIDC Provider. While the Application Pattern defines how an app is structured and what flows it uses, the Provider settings define how the orchestrator responds to specific protocol requests. For instance, an OIDC application sets up the client and related user flow, while the OIDC Provider settings define issuer metadata, supported scopes, and how tokens are handled.

Together, the application configuration and provider settings ensure your integrations are secure, standards-compliant, and ready for production use.

In order to deploy an application you need to assemble the following components:

Application pattern	Defines how your applications consume identity. You will configure Maverics to act as a proxy, OIDC provider, SAML provider or a generalized API. In use cases such as Unified SSO, you can combine these patterns to achieve specific outcomes.
Identity fabric	Defines the identity services you need for your applications. You can also define a Continuity strategy that combines two or more identity services for failover when a identity service is not available.
User flows	Defines the policies for authentication and authorization, claims the application may need as well as plugable service extension points.
Service extensions	GO modules that add custom behaviors like claim transformation, third party API calls, and custom login user flows.

Choosing an application pattern

Pattern	Reason to Use	Example Use Cases
Proxy	To modernize authentication for legacy apps without changing them. The proxy intercepts traffic and handles authentication, header injection, or session translation.	Web apps that only support header-based or basic auth Enforce MFA on a legacy internal web app Modernize authentication Kerberos/LDAP-based web apps without rewrites Resilience and continuous availability by automatically switching to a backup IDP when the main provider is down—no modifications to the application needed.
OIDC Provider	To enable apps that speak OIDC to authenticate using back-end systems that don’t support OIDC (e.g., LDAP, custom APIs, other protocols).	App requires OIDC login, but users live in Active Directory Add FIDO2 to an internal app without modifying the app Add OIDC advanced features like DPOP and transformations of access tokens (claim modification, new attributes, etc..) Federate multiple IDPs Resilience and continuous availability by automatically switching to a backup IDP when the main provider is down—no modifications to the application needed.
SAML Provider	To connect SAML-only apps to modern identity systems or federated user bases. Maverics acts as a bridge from SAML SPs to modern IDPs or orchestration flows.	App supports only SAML, but your org uses Entra ID or Okta Serve a single SAML SP with multiple tenant IDPs Insert MFA and enrich attributes Resilience and continuous availability by automatically switching to a backup IDP when the main provider is down—no modifications to the application needed.

Pattern

Reason to Use

Example Use Cases

Proxy

To modernize authentication for legacy apps without changing them. The proxy intercepts traffic and handles authentication, header injection, or session translation.

Web apps that only support header-based or basic auth
Enforce MFA on a legacy internal web app
Modernize authentication Kerberos/LDAP-based web apps without rewrites
Resilience and continuous availability by automatically switching to a backup IDP when the main provider is down—no modifications to the application needed.

OIDC Provider

To enable apps that speak OIDC to authenticate using back-end systems that don’t support OIDC (e.g., LDAP, custom APIs, other protocols).

App requires OIDC login, but users live in Active Directory
Add FIDO2 to an internal app without modifying the app
Add OIDC advanced features like DPOP and transformations of access tokens (claim modification, new attributes, etc..)
Federate multiple IDPs
Resilience and continuous availability by automatically switching to a backup IDP when the main provider is down—no modifications to the application needed.

SAML Provider

To connect SAML-only apps to modern identity systems or federated user bases. Maverics acts as a bridge from SAML SPs to modern IDPs or orchestration flows.

App supports only SAML, but your org uses Entra ID or Okta
Serve a single SAML SP with multiple tenant IDPs
Insert MFA and enrich attributes
Resilience and continuous availability by automatically switching to a backup IDP when the main provider is down—no modifications to the application needed.

Defining services in your identity fabric

Identity services like Microsoft Entra ID, Okta, HYPR, Auth0, and traditional LDAP directories each play a unique but complementary role within Identity Orchestration. In an orchestrated environment, these services become modular components of an integrated identity fabric, enabling seamless and dynamic user flows across systems without requiring application rewrites.

For example, Entra ID and Okta can act as cloud-based identity providers for workforce authentication, while LDAP directories often provide on-premises user and attribute stores. HYPR introduces phishing-resistant passwordless authentication as a modern security layer, and Auth0 serves as a developer-friendly CIAM solution. Identity Orchestration platforms, like Strata’s Maverics, abstract and unify these services behind a control plane that governs policies, manages authentication, and coordinates authorization in real time.

In your IDP, you will register a new application and in Maverics 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 a LDAP directory you can string them together with a username mapping. This will enable you derive 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.

Defining user flows for your applications

Defining user flows for your applications in Maverics is the process of creating a step-by-step policy that determines how a user authenticates, how their attributes are resolved, and how access is granted to the application. E

ach user flow represents a declarative policy that integrates various identity services—such as IDPs, directories, and service extensions—into a single sequence of authentication, attribute mapping, and authorization decisions. These flows are designed to be modular, reusable, and environment-aware, making it easy to update identity logic without having to modify the underlying applications.

In practice, a user flow may begin with a primary authentication provider, like Entra ID, followed by an attribute resolution step using an LDAP directory or external API, and finally an optional service extension to transform or enrich the session. The flow defines how usernames are mapped across systems, how roles or claims are generated, and how fallbacks are handled if an IDP is unavailable.

Whether you’re enabling SSO, adding MFA, or orchestrating identity continuity across environments, user flows ensure consistent policy enforcement and simplify the deployment of complex identity logic at runtime.

Customizing identity behavior with Service Extensions

Service Extensions in Maverics are custom, pluggable modules written in Go that let you extend and customize identity behavior at key points in a user flow—such as during authentication, attribute resolution, or claims generation. To use them, start by identifying the type of extension you need (e.g., authentication or attribute provider), then create a new extension in the Maverics Console and define the function entry points. Next, upload your Go code and any assets using the built-in editor, and finally, attach the extension to a user flow by selecting it in the relevant phase (e.g., Authentication, Access Token, ID Token). Once configured, commit and deploy your flow to apply the custom logic in production.

Examples of Service Extensions in use:

Dynamic Attribute Loading and Transformation
Use Case: You need to source attributes from multiple data stores—such as an LDAP directory, database, or external API—and then transform or enrich those attributes before passing them to an application or identity provider (IDP).
Example: With a Load Attributes service extension you can map employeeType=FT to employmentStatus=full_time, or pulling in additional attributes from an external API or database during the login flow.

Conditional Flow Routing
Use Case: You want to dynamically route users to different IDPs or flows based on context (e.g., IP, user group, region, time of day).
Example: With a Authentication service extension with assets you can serve a form that will route internal employees to Entra ID and external contractors to Okta CIAM based on their email domain or location.

Just-in-Time (JIT) Provisioning for Identity Continuity
Use Case: In a identity resilience scenario you need to automatically create new user accounts in a secondary failover IDP.
Example: With a Authentication service extension, when a user signs in to a primary IDP, and with a REST API call create a corresponding user in the failover IDP.

Identity Proofing and Verification
Use Case: You need to verify a user’s identity using a third-party identity proofing service before allowing access or completing registration.
Example: With an Authentication Service Extension, you can call an external identity verification API (like Socure, LexisNexis, or ID.me) to validate government-issued ID, perform KYC checks, or confirm a mobile phone number. Based on the response, you can either proceed with authentication or require additional steps for verification.

Custom Authentication Logic
Use Case: You need to implement a custom authentication step that isn’t supported by standard identity providers.
Example: With Authentication service extension you can verify a hardware token or validating a step-up challenge based on device risk level or user context.

Custom Authorization Decisions
Use Case: Enforce complex authorization logic that goes beyond group membership or roles in an IDP.
Example: With a Authorization service extension you can call an external decision engine (like Open Policy Agent or a risk scoring system) to determine if a user should access a specific app or resource.

2025-01-09: Apps restricted to one user flow