Imprivata Web SSO — WS-Federation

Imprivata enables Web SSO integration with Imprivata Enterprise Access Management, WS-Federation and Entra ID.

In this topic, Microsoft 365 is the example of an Entra ID-registered application.

This topic describes configuring the integration between Imprivata Enterprise Access Management as the Identity Provider (IdP) and Microsoft 365 as the Service Provider (SP).

How It Works

Imprivata Web SSO with WS-Federation extends Single Sign-On functionality to Entra ID-registered applications by using the WE-Federation protocol to communicate with Entra ID.

Imprivata Web SSO provides single sign-on and secure multi-factor authentication for web applications, using Entra ID's conditional access policies. Imprivata Web SSO provides an Identity Provider (IdP) web service, with which the WS-Federation-ready applications will integrate. This service in the cloud acts as a front end, with a secure bi-directional connection to your Imprivata appliances, which in turn access Entra ID. Imprivata Web SSO provides identity management, authentication, and policy enforcement to your WS-Federation applications.

By default Entra ID serves as the IdP itself, but in this configuration, Entra ID federates user authentication, redirecting all user authentication requests to Imprivata Enterprise Access Management (the IdP) using WS-Federation.

Imprivata Enterprise Access Management's IdP Admin service, exposes public REST API for EAM SSO administrative functions. This is the same service used for SAML and OIDC-based WebSSO with Imprivata Enterprise Access Management.

Your on-premises Microsoft Active Directory server provides user identity management for Windows workstations and your Imprivata enterprise. It is required to maintain the Microsoft hybrid Entra ID model.

Your Imprivata enterprise must be provisioned to Imprivata Cloud so it can establish connection to cloud services responsible for WS-Federation functionality. It also serves the Imprivata Admin Console web application.

IMPORTANT:

The User Principal Name (UPN) on the on-premises AD must match the UPN on Microsoft Entra.

NOTE:

Imprivata Web SSO only supports Service Provider-initiated interactions. Identity Provider-initiated interactions, where the user points their browser to the IdP, are not supported.

Before You Begin

IMPORTANT:

If your enterprise is already federated with Imprivata as the IdP with the SAML protocol, you must first "un-federate" Entra ID from Imprivata and then "re-federate" using the process outlined here.

When you federate again with Imprivata IdP with WS-Federation, Entra ID is in "Managed" mode, using a different set of Powershell commands.

You can determine if you are already federated in Entra ID with the following command in Powershell: GET -PreferredAuthenticationProtocol against your Entra ID instance. This command should return the value <SAMLP> if you are already federated.

Once you have un-federated from Imprivata as the IdP, set the flag for the new federation: <-Authentication Federated> (see below).

CAUTION:

For your administrator to be able to configure Web SSO as described here, the administrator must be licensed for SSO/AM.

All users must be enrolled with Imprivata ID on their mobile device before this integration is completed.

IMPORTANT:

In Entra ID, turn off Passwordless/Passthrough before this integration. Otherwise, MS Authenticator will continue to be used for AuthN instead of Imprivata ID.

In Entra ID, make the change here: Security > Authentication Methods > Microsoft Authenticator > Authentication Mode

For more details, see Microsoft documentation: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta

 

Microsoft Entra Connect

Microsoft Entra Connect (formerly Azure AD Connect) is required for Ws-Fed integration with Imprivata. Instructions for Microsoft Entra Connect are found online in the Microsoft Learn documentation.

Add Application Using WS-Federation

Unlike other applications that require an application profile per app, in this scenario, you only create one application profile per domain, connected with Entra ID.

Only the superadmin role is able to configure Web SSO application profiles:

  1. In the Imprivata Admin Console, go to Applications > Single sign-on application profiles.

    All Single sign-on application profiles, including conventional Imprivata APG profiles, Mobile app profiles, SAML application profiles, and OpenID Connect application profiles, are all managed from this page.

  2. Click Add App Profile Application using WS-Federation. The Add application using WS-Federation page opens.

  3. Give the application profile a name. This name is only visible to administrators.

    If you want a different name for your users to see when they log in, Give the application a user-friendly name.

  4. In the Redirect URI field, enter, as an example, https://login.microsoftonline.com/login.srf

  5. Click Save.

    A new application profile is created. The Imprivata IdP Ws Federation metadata window will open. Your Microsoft 365 enterprise requires this information to complete the integration. You can copy this information now, or return to this application profile at any time to acquire it.

Set IdP Metadata with Microsoft Entra ID

Set the IdP metadata for this configuration with Microsoft Entra ID. All five URL values from the IdP metadata, and the IdP certificate are entered here:

  1. In PowerShell, type the following command to install the necessary modules: Install-Module -Name Microsoft.Graph

    This command only needs to be executed once.

  2. Enter this command next: Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"

  3. Enter your administrator credential for your Microsoft 365 tenant when prompted, and accept prompt for permissions.

  4. If your domain isnot already federated, enter the following.

    New-MgDomainFederationConfiguration

    -DomainId <Domain name>

    -ActiveSignInUri <Active URL from IdP metadata >

    -IssuerUri <Issuer URL from IdP metadata>

    -MetadataExchangeUri <Metadata URL from IdP metadata>

    -PassiveSignInUri <Passive URL from IdP metadata>

    -SignOutUri <Logoff URL from IdP metadata>

    -SigningCertificate <Certificate data>

    -FederatedIdpMfaBehavior "enforceMfaByFederatedIdp"

    -PreferredAuthenticationProtocol wsFed | Format-List

    CAUTION:

    The configuration command must not contain new lines/line breaks.

    Remove all spaces from the certificate text.

  5. If your domain is already federated, enter the following:

    Get-MgDomainFederationConfiguration -DomainId <Domain name> | Format-List

    Copy the ID of federation configuration.

    Update-MgDomainFederationConfiguration

    -DomainId <Domain name>

    -InternalDomainFederationId <ID copied above>

    -ActiveSignInUri <Active URL from IdP metadata>

    -IssuerUri <Issuer URL from IdP metadata>

    -MetadataExchangeUri <Metadata URL from IdP metadata>

    -PassiveSignInUri <Passive URL from IdP metadata>

    -SignOutUri <Logoff URL from IdP metadata>

    -SigningCertificate <Certificate data>

    -FederatedIdpMfaBehavior "enforceMfaByFederatedIdp"

    -PreferredAuthenticationProtocol wsFed | Format-List

    CAUTION:

    The configuration command must not contain new lines/line breaks.

    Remove all spaces from the certificate text.

  6. Check your work with the command: Get-MgDomainFederationConfiguration -DomainId <Domain name> | Format-List

Rolling Back to Managed Mode

The rollback procedure to switch back to Managed mode, if necessary:

Update-MgDomain -DomainId <Domain name> -AuthenticationType "Managed"

Updating Certificate Data

When the certificate data needs to be updated (for example, when the certificate is expired):

Get-MgDomainFederationConfiguration -DomainId <Domain name> | Format-List

Copy the ID of federation configuration.

Update-MgDomainFederationConfiguration

-DomainId <Domain name>

-InternalDomainFederationId <ID copied above>

-SigningCertificate <Certificate data>

IT Pilot — Deploy to Select Users

Imprivata Web SSO application profiles offer flexible deployment options.

Deploy your profile to select users for testing:

  1. In the Imprivata Admin Console, go to ApplicationsSingle sign-on application profiles, find your App Profile, and click Not Deployed.

  2. Click Deploy This Application?

  3. Un-check Deploy to All Users and Groups.

  4. Check the domain your test users are located in.

  5. Check These OUs, groups and users

  6. Specify your test users.

  7. Click Save.

  8. On the list of application profiles, check the box next to the profile and click Deploy.

Deploy To Users and Groups

Imprivata Web SSO application profiles offer flexible deployment options.

Deploy your profile to specific OUs, users, and groups as needed:

  1. In the Imprivata Admin Console, go to ApplicationsSingle sign-on application profiles, find your App Profile, and click Not Deployed or Not Deployed.
  2. Check Deploy This Application.
  3. You can Deploy to All Users and Groups, or uncheck this option and deploy to select OUs, users, and groups.
  4. Check the domain your users are located in.
  5. Select For All Users (in this domain) or check These OUs, groups and users
  6. Select specific OUs, groups, and users as needed.
  7. Click Save.
  8. On the list of application profiles, check the box next to the profile and click Deploy.

For complete details, see Deploying Application Profiles.

NOTE:

All Imprivata users synced to the same domain in Active Directory as the Service Provider or Relying Party users, who are licensed for Single Sign On with Imprivata, will immediately be able to log into the Web SSO app using their username and password authenticated by Imprivata Web SSO.

When the workstation has the Imprivata agent online and the user is already logged into the workstation, the user will not be prompted for their credentials.

For complete Web SSO workflow details, see Expected Endpoint Workflows.

BEST PRACTICE:

Microsoft recommends 24 hours for federation to propagate to all of its servers. This is relative to the number of servers, not the number of users. Deploy at the beginning of a weekend or when the load on Microsoft servers is lighter. If you're replacing an existing federated domain, propagation typically only takes 30 minutes.

Expected Endpoint Workflows

The expected Imprivata Web SSO workflow has the following variations:

Imprivata Agent Online

  1. The user logs into desktop with Imprivata Enterprise Access Management.

  2. The user provides the URL for an app enabled for Imprivata Web SSO.

  3. The app opens. The user does not need to log into it manually.

    Subsequent apps are automatically authenticated within the same browser and the same session.

    If the user closes an app without logging out of the app, he can return to the app during the same session without logging in again.

Imprivata Agent Not Present or Unavailable

  1. The user provides the URL for an app enabled for Imprivata Web SSO.

  2. The user is prompted to log in:

    • If the user is included in a user policy associated with the Imprivata Web SSO workflow, he will be prompted to complete the Log In workflow.
    • If the user is not included in a user policy associated with the Imprivata Web SSO workflow, he will be prompted to authenticate with username and password.
  3. The app opens.

    Subsequent apps are automatically authenticated within the same browser and the same session.

    If the user closes an app without logging out of the app, he can return to the app during the same session without logging in again.

Imprivata Web SSO on an Unsupported Browser

The expected Imprivata Web SSO workflow on an unsupported browser is the same as when the Imprivata agent is not present or unavailable:

  1. The user provides the URL for an app enabled for Imprivata Web SSO.

  2. The user is prompted to log in:

    • If the user is included in a user policy associated with the Imprivata Web SSO workflow, he will be prompted to complete the Log In workflow.
    • If the user is not included in a user policy associated with the Imprivata Web SSO workflow, he will be prompted to authenticate with username and password.
  3. The app opens.

    Subsequent apps are automatically authenticated within the same browser and the same session.

    If the user closes an app without logging out of the app, he can return to the app during the same session without logging in again.

For complete details on supported browsers, see Imprivata Enterprise Access Management Supported Components

When Another User Logs In

When a subsequent user logs into a workstation, the Imprivata agent terminates the IdP session of the previous user.

Imprivata Web SSO cannot terminate user sessions:

  • In browsers other than Microsoft Edge or Google Chrome;

  • On workstations where the Imprivata agent is not present or unavailable;

  • For applications not enabled for Imprivata Web SSO;

BEST PRACTICE:

Turn off persistent cookies for Relying Parties; this prevents a user from accessing another user's session after a Fast User Switch.

Manually log out of applications where Imprivata Web SSO cannot terminate the user session;

Close browser windows.

Optional — Web App Login Configuration

Configure the appearance of the web login application screens with the logo and color of your enterprise, and set a custom session log out value:

  1. In the Imprivata Admin Console, go to the gear iconWeb app login configuration

    • Select a background color for the login screen (hexidecimal value);
    • Upload a PNG, GIF, or JPG logo (200 x 150 pixels, 250 KB max)
  2. User sessions are logged out after 2 hours by default. Turn off this automatic logout, or select a value between 30 minutes and 4 days.
  3. Click Save.

Troubleshooting

Verify proper integration of Imprivata Web SSO (IdP) with the Relying Party (RP).

  • Imprivata IdP configuration (accessed through Imprivata Admin Console);

  • Relying Party SSO configuration (Relying Party administration)

  • Endpoint (device from which the user accesses the Relying Party application).

Replacing Expiring Certificates

NOTE:

The IdP certificate for your Imprivata enterprise expires two years after it is enabled. You will receive an alert on the Imprivata Admin Console beginning 60 days before it expires.