2. Identity, Authentication Protocols and Cross-site Access

Download a PDF of this information.

This section defines the core decision categories and technical identity configurations that underpin all ECC reference architectures. It covers authentication directory choices, Hyperdrive delivery models, EPCS authority, protocol options (LDAP, non-LDAP, OIDC, SAML, Entra ID/ROPC), domain trust configurations, endpoint types, and cross-site users scenarios.

2.1 Core Decision Categories

Every ECC architecture can be decomposed into three primary decision axes:

  • A: Authentication Directory – how does a user authenticate into an endpoint and application virtualization, if required, how does a user authenticate into Epic Hyperdrive (Host directory vs ECC directory).

  • B: Hyperdrive Delivery Model – how Hyperdrive is launched (Local Install, Host-shared application virtualization, ECC-shared application virtualization, ECC-dedicated application virtualization).

  • C: EPCS Authentication – which organization’s EAM instance controls EPCS authentication.

2.2 Epic Login Identity and Protocol

The source of identity/directories used to authenticate users into Epic will dictate the protocol used. This has a major impact on ECC design. The source of identity will dictate the configuration within EAM and within Epic for AD authentication using. The supported configuration options within EAM for authentication to Epic are: LDAP and non-LDAP.

OIDC is used for EPCS workflows and does not replace the Epic login configuration. Entra ID ROPC is not supported in this reference architecture.

2.2.1 ECC LDAP vs Non-LDAP Epic Authentication

LDAP configuration: Epic authenticates identities from the directory used by the ECC site’s EAM instance.

Non-LDAP configuration: Epic is not bound to ECC site’s directory as the authentication source and Epic Hyperdrive credentials must be captured by the EAM instance.

2.2.2 SAML Authentication with Epic (LDAP and Non-LDAP Configuration)

SAML can be used for Epic authentication in both LDAP and non-LDAP Imprivata enterprises.

  • In LDAP-configured scenarios, EAM still synchronizes identities from the directory and SAML token is used to authenticate the user into Epic.

  • In non-LDAP-configured scenarios, Imprivata uses Epic Identity Provider to capture Epic username that will be used in SAML token to authenticate into Epic session.

Each Hyperdrive login device must be configured to reference the SAML certificate, downloaded from the ECC Imprivata appliance.

Each Hyperdrive login device must be configured at each ECC site.

2.2.3 Entra ID (Azure AD) ROPC with Epic and Imprivata Connector

The Imprivata Connector for Epic Hyperdriveonly interacts with Generic Authentication Epic APIs for Single Sign-On. The connector does not interact with Entra ID.

Imprivata does not officially support Entra ID ROPC configurations.

2.2.4 When Slingshot is Required

Use Slingshot when Hyperdrive is delivered as a published application (host-shared, ECC-shared, or ECC-dedicated) and you need SSO or tap-and-go into the published session. Slingshot is also required for multi-hop launch patterns. Slingshot is usually not required for locally installed Hyperdrive (except optional auto-launch behavior).

2.3 OIDC-based EPCS

OIDC-based EPCS changes how EPCS authentication is performed but it does not change how users log into endpoints or how Epic sessions are created. The Imprivata agent is used to complete the supervised enrollment of the EPCS provider. The Imprivata agent and Imprivata Connector do not need to be installed to perform OIDC-based EPCS authentication.

Use this section to determine when OIDC-based EPCS applies, what endpoint and session requirements exist and how the design impacts cross-site EPCS providers (host-provided EPCS: single enrollment. ECC-site provided EPCS: per-site enrollment).

2.3.1 OIDC-based EPCS for Windows Endpoints

As EPCS moves toward OIDC-based authentication, Windows endpoints use the Imprivata agent and Imprivata Connector for workstation logon and Hyperdrive SSO, but EPCS authentications are executed via OIDC instead of legacy Confirm ID integration.

  • For host-provided EPCS, Hyperdrive is configured to authenticate against the host’s EPCS OIDC environment.

  • For ECC-provided EPCS, Hyperdrive is configured to authenticate against the ECC site’s OIDC EPCS environment.

The Hyperdrive delivery model (local install vs application virtualization) does not change; only the protocol used for EPCS does.

When using host-provided EPCS and locally installed Hyperdrive, EPCS authentication must be performed via OIDC (See Section 6).

2.3.2 OIDC for Mac and Agentless Endpoints

For Mac or other agentless endpoints where a native Imprivata agent cannot be installed, Hyperdrive or Epic access may occur via a browser or a light client container. In this case, workstation logon is not Imprivata-controlled. EPCS authentications rely on OIDC through Epic’s web layer and upstream identity providers.

An Epic username can only be captured through the Imprivata agent and Imprivata Connector. An Epic username cannot be captured via OIDC.

Design sessions should explicitly identify which endpoints are truly agentless and whether clinical users will instead access Hyperdrive via a Windows VDI or application virtualization session where Imprivata components are present.

2.4 Cross-site Users (Standard Users and EPCS Providers)

A cross-site user is any user who works across an organization boundary between a host and one or more ECC sites.

User Types

  • Standard User: needs SSO to endpoints and Epic Hyperdrive

  • EPCS Provider: Standard user plus EPCS

What cross-site access changes

  • Epic login identity: Use one Epic identity model across locations (host directory vs ECC site directory).

  • SSO mapping: The endpoint or session-host identity must map to the correct Epic user (LDAP vs non-LDAP).

  • EPCS enrollment scope (EPCS providers): Host-owned EPCS supports one enrollment across sites. ECC site-owned EPCS requires supervised enrollment in each EAM instance where the provider will prescribe.

  • OIDC-based EPCS: Route the OIDC flow to the EAM instance that owns the provider’s EPCS enrollment.

2.5 Domain Trust Configurations and Endpoint Types (Type 1, Type 2)

Active Directory trust direction between the host and ECC site domains determines who can sign in to which endpoints and session hosts. It also drives whether Type 1 (private) or Type 2 (shared) endpoints are practical for cross-site users.

2.5.1 Trust Configurations (AD)

  • One-way trust (Host trusts ECC site): host accepts ECC site accounts; ECC site does not accept host accounts.

  • One-way trust (ECC site trusts Host): ECC site accepts host accounts; host does not accept ECC site accounts.

  • Two-way trust: both domains accept each other’s accounts.

  • No trust: host and ECC site domains do not trust each other. Users can authenticate only within their own domain. ECC site endpoints accept only ECC site accounts, and host users cannot sign in to ECC site domain-joined endpoints (and vice versa).

2.5.2 Endpoint Type Implications

  • Type 1 (private) endpoints are suited to users who primarily use a single device and domain identity.

  • Type 2 (shared) endpoints are preferred for shared clinical workstations where multiple providers from different domains log on to the same device. In cross-organization settings, Type 2 endpoints help support cross-site users and reduce friction at the workstation.

For cross-site user scenarios, favor Type 2 shared endpoints in locations where multiple organizations’ providers will be working. Confirm that the direction of the AD trust matches the expected roam direction; otherwise clinicians may not be able to log into the workstations where they need to provide care.