Imprivata PAMImprivata Web SSO Setup with SAML 2.0

Configuring Imprivata Web SSO establishes trust between Imprivata as the Identity Provider (IdP) and Imprivata PAM as the Service Provider (SP).

Requirements

Before you begin the integration, ensure that the following requirements are met:

  • A working Imprivata PAM deployment with the Federated Sign-In experience.

  • Access to your existing Imprivata PAM host server. You will need to update files and restart services.

  • Access to the Imprivata Admin Console to configure the authentication services.

  • If users are created and managed in Imprivata OneSign, then a matching user must also be created as an Imprivata PAM Local User.

  • If users are synched from Active Directory to Imprivata PAM, then you must also integrate Imprivata PAM with the same Active Directory.

IdP and SP Metadata

Imprivata Web SSO (IdP) and Imprivata PAM (SP) need metadata from each other. Open both consoles at the same time and import this metadata as follows.

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. When the Service Provider or Relying Party certificate is expiring for a web app enabled for Web SSO, you will receive an alert 90 days in advance.

Imprivata Admin Console: Add SAML Application

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 managed from this page.

  2. Click Add App Profile Application using SAML. The Add SAML application page opens.

  3. Give the Imprivata PAM 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 Service provider (SP) metadata section, specify the following information:

    1. For NameID format preference, select Unspecified.

    2. For Returned Attribute:

      1. Select User login name – Pre W2K (sAMAccountName) if Imprivata PAM is configured to authenticate using sAMAccountName. This is the default configuration in Imprivata PAM.

      2. Select User login name (userPrincipalName) if Imprivata PAM is configured to authenticate using UPN.

  5. In the Identity provider (IdP) metadata section, click View and copy Imprivata (IdP) SAML metadata.

  6. Click the copy icon to copy the Metadata URL to your clipboard.

    NOTE:

    You will use this value on the Imprivata PAM host server in the next task.

  7. Leave the Imprivata Admin Console open.

    After configuring files on the Imprivata PAM host server in the next task, you will return to the Imprivata Admin Console to complete the configuration.

Imprivata PAM Host Server: Configuring Imprivata PAM for Imprivata OneSign

Log in to your Imprivata PAM host server.

  1. Open the file $PAM_HOME\web\conf\catalina.properties in a text editor.

  2. Locate the section that is labelled # CAS and add the following new lines:

    # Imprivata OneSign SSO SAML
    cas.authn.pac4j.saml[0].clientName=OneSign Login
    cas.authn.pac4j.saml[0].keystorePassword={password}
    cas.authn.pac4j.saml[0].privateKeyPassword={password}
    cas.authn.pac4j.saml[0].serviceProviderEntityId=https://xtam.company.com/xtam/
    cas.authn.pac4j.saml[0].serviceProviderMetadataPath={imprivatasso.xml}
    cas.authn.pac4j.saml[0].keystorePath={samlKeystoreImprivataSSO.jks}
    cas.authn.pac4j.saml[0].identityProviderMetadataPath={path}
    cas.authn.pac4j.saml[0].maximumAuthenticationLifetime=2073600

    where

    • cas.authn.pac4j.saml[0].keystorePassword={password} is an alphanumeric password you create.

    • cas.authn.pac4j.saml[0].privateKeyPassword={password} is an alphanumeric password you create.

    • cas.authn.pac4j.saml[0].serviceProviderEntityId=https://xtam.company.com/xtam/ is the URL for your full https Imprivata PAM login page URL, ending with /xtam/.

    • cas.authn.pac4j.saml[0].serviceProviderMetadataPath={imprivatasso.xml} is the full path and file name of the imprivatasso.xml file that will be created after you restart the Imprivata PAM service.

      For example: C:/pam/content/keys/imprivatasso.xml. Use forward slashes instead of backslashes.

      NOTE:

      Take note of this location; you will upload this file to your Imprivata SAML application in the Imprivata Admin Console.

    • cas.authn.pac4j.saml[0].keystorePath={samlKeystoreImprivataSSO.jks} defines a path and name for the Imprivata PAM auto-generated key.

      For example, C:/pam/content/keys/samlKeystoreImprivataSSO.jks. Use forward slashes instead of backslashes.

    • cas.authn.pac4j.saml[0].identityProviderMetadataPath={path} - Enter the full URL copied from the Metadata URL section of your Imprivata SAML configuration in the Imprivata Admin Console, from Step 6 above.

      For example, https://idp.cloud.imprivata.com/{yourTenantID}/saml2.

  3. Save and close this file.

  4. Restart the PamManagement (Windows) or pammanager (Linux) service.

  5. After the service has fully restarted, open your browser and navigate to the Imprivata PAM login page. The login page displays a new red button with the Imprivata OneSign Login.

Imprivata Admin Console: Complete the Imprivata OneSign Configuration

  1. In the Imprivata Admin Console, return to the Add application using SAML page.

  2. In the Service provider (SP) metadata section, click Get SAML metadata.

  3. Select From XML and click Browse. Select the imprivatasso.xml that you created in Step 2 above. For example: C:/pam/content/keys/imprivatasso.xml. Click OK.

  4. The Imprivata Admin Console processes the XML file and displays the relevant information in the Service provider (SP) metadata section. Review and confirm that the information is accurate.

    Click Save.

User Management

Consider how your SP manages its users: To successfully authenticate, the user information managed by your SP (SAML NameID, username, password, and so on) and the user data synchronized by Imprivata (the IdP) from your Active Directory (AD) must match. In the Imprivata Needs section, set the NameID format preference and User Attributes as needed:

  • AD Sync — If your SP syncs its user data with the same AD users and groups as your Imprivata IdP, then no special configuration should be needed.
  • Create Users Manually in SP — If your SP admin creates user accounts manually, they must use the same NameID format (for example User Principal Name (UPN), email address, and sAMAccountName), so the Imprivata IdP can successfully match them.
  • Automatic Account Provisioning — When the SP automatically creates an account as the user logs in for the first time. This functionality is supported in Imprivata Web SSO.

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.

Test the Login Integration

  1. Return to the Imprivata PAM login page and click OneSign Login.

  2. You are directed to the Imprivata login page. Enter your credentials that are both valid in Imprivata OneSign for the Imprivata PAM deployed application and valid with Imprivata PAM. Click Log in.

  3. (Optional). If Imprivata ID is available for your account, you may be prompted to authenticate with your Imprivata ID, or to enroll your device. Continue with Imprivata ID, or click Not now to perform the enrollment at a later date.

  4. After the SAML authentication is successful, your browser redirects back into Imprivata PAM, using Imprivata OneSign.

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 enterprise does not have an Imprivata Enterprise Access Management Remote Access license, he will be prompted to authenticate with username and password.
    • If the user is included in a user policy associated with the MFA Remote Access Log In workflow, he will be prompted to complete the Log In workflow.
    • If the user is not included in a user policy associated with the MFA Remote Access Log In 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 enterprise does not have an Imprivata Enterprise Access Management Remote Access license, he will be prompted to authenticate with username and password.
    • If the user is included in a user policy associated with the MFA Remote Access Log In workflow, he will be prompted to complete the Log In workflow.
    • If the user is not included in a user policy associated with the MFA Remote Access Log In 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;
  • For SAML applications that track the SP session with a persistent cookie.
CAUTION:

In an Imprivata environment where applications are federated with Imprivata Web SSO IdP, all users need to be licensed for Imprivata Web SSO. As soon as the integration between Imprivata and the web application is completed, users not licensed for Imprivata Web SSO won’t be able to access the application. Imprivata does not support manual password authentication in this environment.

BEST PRACTICE:

Implement Single Log Out for your Web SSO-enabled applications (where supported);

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 — Number Matching

Multi-factor authentication fatigue attacks, also known as "MFA bombing", are a common cyberattack strategy. In an MFA fatigue attack, the attacker sends MFA push notifications to a registered user. The user may accidentally or absent-mindedly accept one of these push notifications, giving the attacker access to protected resources. This type of attack is generally preceded by phishing of the registered user’s login credentials.

With Imprivata’s Number Matching authentication enabled, users must enter their username and password on their endpoint computer, then a 2-digit code into Imprivata ID that matches the randomly generated number displayed on the application being accessed.

This reduces the risk of the user accepting a push notification they did not initiate, and keeps your digital assets out of the hands of bad actors.

Setup

  1. In the Imprivata Admin Console, go to UsersWorkflow Policy.

  2. On the MFA workflow policy page > Authentication Options, select Require Web SSO and remote access users to enter a code when using Imprivata ID for MFA (number matching)

NOTE:

Number Matching authentication is available for Enterprise Access Management Remote Access and Imprivata WebSSO only. Number Matching authentication is not available for the feature Imprivata ID for Windows Access.

This feature does not add Imprivata ID push notifications with number matching to workflows that do not already require the user to accept push notifications. This feature only requires users to enter the code within workflows that already require the user to accept Imprivata ID push notifications. See Expected Workflow, below.

Expected Workflow

In this example, the user is at an endpoint computer where the Imprivata agent is not present, and/or they are completing WebSSO or Remote Access workflows that require the user to accept an Imprivata ID push notification:

  1. The user is logging in remotely, or provides the URL for an app enabled for Imprivata Web SSO.

  2. The user is prompted to enter their username and password.

  3. After the user successfully enters their username and password, they are prompted to approve a push notification sent to their enrolled Imprivata ID. A two-digit code will be shown on the application or resource being accessed.

  4. Imprivata ID will display the username and the application the user is accessing.

    The code expires in 30 seconds.

  5. After the user enters the two-digit code on Imprivata ID, they are given access to the application/resource.

For WebSSO, 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.

If the user fails to enter the code correctly, or the code expires, the user must begin authentication again.

CAUTION:

For this workflow, users must upgrade to the latest version of Imprivata ID on their mobile device. Users with versions of Imprivata ID before 2023.2 (iOS) or 2023.1 (Android) will not have the option to simply accept a push notification; they must manually enter the six-digit Token Code to authenticate to all sites.

Optional — Web Login Customization

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.

Optional — Specify The Returned Attribute

When required by the SP, you can specify the returned attribute the IdP sends to the SP when the SP NameID format preference is unspecified.

In the Service Provider (SP) metadata section, when the NameID format preference field is set to Unspecified,

you can set the Returned Attribute field to:

  • Email address (mail)
  • User logon name (userPrincipalName)
  • User logon name - Pre W2K (sAMAccountName)
  • User security identifier (objectSID)
  • User unique ID (UUID)

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. When the Service Provider or Relying Party certificate is expiring for a web app enabled for Web SSO, you will receive an alert 90 days in advance.