Salesforce: Imprivata Web SSO with OpenID Connect Setup

Configuring Imprivata Web SSO with OpenID Connect establishes trust between Imprivata as the Identity Provider (IdP) and Salesforce as the Relying Party (RP).

How It Works

Imprivata Web SSO with OpenID Connect extends Single Sign-On functionality to OpenID Connect applications. Imprivata Web SSO uses OpenID Connect 1.0 standards.

Imprivata Web SSO provides single sign on and secure multi-factor authentication for web applications. Imprivata Web SSO provides an OpenID Connect Identity Provider (IdP) web service, with which the OpenID Connect 1.0-ready applications will integrate. This service in the cloud acts as a front end, with a secure bi-directional connection to your on-premises Imprivata appliances, which in turn access Active Directory. Imprivata Web SSO provides identity management, authentication, and policy enforcement to your OpenID Connect applications inside your firewall, extending the Imprivata experience when users themselves access these applications from outside the firewall.

1. The user points her browser to the application — the Relying Party (RP).

   You have configured the application to integrate with Imprivata as the Identity Provider (IdP).

2. The application redirects the user's browser to the IdP.

3. The IdP executes Imprivata's login screen.

4. The user supplies the necessary credentials to authenticate.

   NOTE:

   When the workstation has the Imprivata agent online and the user already logged into the workstation, the user is not prompted for their credentials. See Expected Endpoint Workflows.

5. The IdP generates an Access Token and an ID Token, and provides them to the RP.

6. The RP grants access to the user, logging her into the application.

Imprivata Appliance Configuration

Validate OpenID Connect integration settings on the Imprivata Admin Console:

Setting	Required / Optional	Imprivata Admin Console location
Imprivata OneSign 7.6 or later	Required	Help menu
Imprivata Single Sign On is licensed	Required	Gear menu > License
Imprivata enterprise is provisioned and connected to the cloud	Required	Gear menu > Cloud connection
OpenID Connect applications are added and enabled in Imprivata Admin Console	Required	Applications > Single sign-on application profiles
OpenID Connect applications are deployed to selected set of users	Required	Applications > Single sign-on application profiles
Imprivata users are assigned to user policy enabled for Single Sign On	Required	Users > User policies
User policies are assigned to Remote Access workflow	Optional; required for multi-factor authentication when the Imprivata agent is offline or not present	Users > Workflow policy

Cloud Connection

Imprivata Services will enter the Enterprise ID and one-time cloud provisioning code required to establish trust between your Imprivata enterprise and the Imprivata cloud:

1. If you're not on the Cloud Connection page already: In the Imprivata Admin Console, click the gear icon > Cloud connection.
2. Services will enter your Enterprise ID and cloud provisioning code.
3. Click Establish trust.

BEST PRACTICE:

The cloud connection must be established by Imprivata Services.

Cloud Connection Status

You can review the status of your enterprise's connection to the Imprivata cloud at any time. Status notifications are displayed on the Imprivata Admin Console, and the cloud connection status of every appliance at every site is also available:

1. In the Imprivata Admin Console, go to the gear icon > Cloud connection.

2. Every appliance host is listed with its status. If there are problems with a connection, recommendations for resolving the problem are displayed here.

Add Salesforce as OpenID Connect 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, and SAML application profiles, are all managed from this page.

2. Click Add App Profile > Web application using OpenID Connect. The Add web application using OpenID Connect page opens.

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

   Give the application a user-friendly name. This is the name your users will see when they log in.

4. Click Generate client credentials.
   Leave the Imprivata Admin Console open; Open Salesforce in another window.

Salesforce: New Authentication Provider

1. Log into Salesforce in your test or production environment. Click on your user icon and switch to Salesforce Classic.

2. Go to Setup > Security Controls > Auth. Providers

3. Click New to create Imprivata as the new Authentication Provider.

4. Choose OpenID Connect and fill in the form:

   • Set a name for Imprivata as the Authentication Provider;

   • Use the Client Credentials generated in the previous section. Enter them here as Consumer Key and Secret Key.
     

5. On the Imprivata Admin Console, click on View and copy Imprivata (IdP) OpenID Connect metadata.

6. Copy the following URLs and paste them into the Salesforce Auth. Provider form:
   

   • Authorize endpoint URL

   • Token endpoint URL

   • User info endpoint URL

   • Logout URL

7. In the Default Scopes field enter openid profile email phone.

Salesforce — Set Registration Handler Script

1. Open another Salesforce window; go to Develop > Apex Classes > New

2. Paste this script into empty area from Apex Class tab:
   

   Registration Handler Script

   global class SocialRegHandler implements Auth.RegistrationHandler{

   private static final String ORG_SUFFIX = '.sso.badge.org';

   public static final String DEFAULT_ACCOUNTNAME = 'MADD';

   /**

   * Let anyone register as long as the required fields are supplied

   *

   * We require email, lastName, firstName

   *

   * @data - the user's info from the Auth Provider

   **/

   global boolean canCreateUser(Auth.UserData data) {

   System.debug('canCreateUser was called for ' + (data != null ? data.email : 'null'));

   Boolean retVal = (data != null

   && data.email != null

   && data.lastName != null

   && data.firstName != null);

   System.debug('data.username='+data.username);

   System.debug('data.email='+data.email);

   System.debug('data.lastName='+data.lastName);

   System.debug('data.firstName='+data.firstName);

   return retVal;

   }

   /**

   * Create the User - A required method to implement the Handler Interface

   *

   * @param portalId - Id of the Community

   * @param data - Auth Provider user data describing the User to create

   *

   * @return User that has been initialized

   **/

   global User createUser(Id portalId, Auth.UserData data){

   System.debug('can create ' + canCreateUser(data));

   if(canCreateUser(data)) {

   if(data.email != null){

   User u = [Select Id , username from User where username =: data.email];

   System.debug('user ' + u);

   return u;

   } else {

   return null;

   }

   }

   // Is this a Community Context?

   if(data.attributeMap.containsKey('sfdc_networkid')) {

   System.debug('Registering Community user: ' + data.email);

   // To keep things modular, we're creating the PersonAccount in a separate method

   // Id contactId = createPersonAccountContact(data);

   Contact c = new Contact();

   c.LastName = data.lastName;

   c.FirstName = data.FirstName;

   c.Email = data.email;

   insert c;

    

   // You'd likely use other logic to assign the Profile

   Profile p = [SELECT Id FROM profile WHERE name='MADD Customer Community User'];

   // Keeping it modular, we initialize the user in another method

   User u = createUser(data,p);

    

   u.contactId = c.id;

   return u;

   } else {

   //This is not a community, so we Assign an internal profile

   Profile p = [SELECT Id FROM profile WHERE name='Standard User'];

    

   // Keeping it modular, we initialize the user in another method

   User u = createUser(data,p);

   return u;

   }

   }

   /**

   * Update the user

   * @param portalId - Id of the Community

   * @param data - Auth Provider user data describing the User to create

   **/

   global void updateUser(Id userId, Id portalId, Auth.UserData data){

   System.debug('Update User called for: ' + data.email);

   User u = new User(id=userId);

   u.email = data.email;

   u.lastName = data.lastName;

   u.firstName = data.firstName;

   update(u);

   }

   /**

   * Create a PersonAccount for the contact

   *

   * @param data - Facebook provided context for this User

   private Id createPersonAccountContact(Auth.UserData data) {

   Account person = new Account();

   person.LastName = data.lastName;

   person.FirstName = data.FirstName;

   person.personEmail = data.email;

   person.RecordTypeId = [Select Id From RecordType

   Where SobjectType='Account'

   AND isPersonType=true LIMIT 1].id;

   insert person;

   System.debug('Person Account created for ' + data.email + ' id=' + person.id);

   /**

   * This next step is necessary to get a valid contact Id,

   * it won't exist until the PersonAcct is saved

   Account a = [Select PersonContactId From Account Where Id = :person.Id];

   return a.PersonContactId;

   }

   **/

   /**

   * Create and initialize the User but don't save it yet

   *

   * @param data - the provided User context from FaceBook

   * @param p - the Profile we are going to assign to this user

   *

   * @return User that has been initialized but not Saved

   **/

   private User createUser(Auth.UserData data, Profile p) {

   User u = new User();

   u.username = data.email + ORG_SUFFIX;

   u.email = data.email;

   u.lastName = data.lastName;

   u.firstName = data.firstName;

   String alias = data.firstName + data.lastName;

    

   //Alias must be 8 characters or less

   if(alias.length() > 8) {

   alias = alias.substring(0, 8);

   }

   u.alias = alias;

   u.languagelocalekey = UserInfo.getLocale();

   u.localesidkey = UserInfo.getLocale();

   u.emailEncodingKey = 'UTF-8';

   u.timeZoneSidKey = 'America/Los_Angeles';

   u.profileId = p.Id;

   return u;

   }

   }

3. Optional — In the first line of the script, you can replace the name for the Registration Handler, instead of "SocialRegHandler".
4. Click Save.
5. In the Auth. Provider Edit window, go to the Registration Handler field and click the magnifying glass icon.
6. In the Lookup window, search for the script you just created, by the name SocialRegHandler (or the custom name you chose above).

7. In the Auth. Provider Edit window > Execute Registration As field, choose yourself.

8. Click Save.

9. Scroll down and copy the Callback URL.

10. In the Imprivata Admin Console, paste this URL into the Redirect URI field.

Salesforce — Authentication Configuration

1. In Salesforce, go to Domain Management > My Domain > Edit.

2. Find your Auth. Provider from the list, and click Save.

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 Applications > Single 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 Applications > Single 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.

Expected Endpoint Workflows

The expected Imprivata Web SSO workflow has the following variations:

Imprivata Agent Online

1. The user logs into desktop with Imprivata OneSign.

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 Confirm ID 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 Imprivata Confirm ID 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 Imprivata Confirm ID 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 a Imprivata-enabled Mobile Device

1. The user logs into the device with Imprivata OneSign.

2. The user launches an app enabled for Imprivata Web SSO.

3. The user is prompted to authenticate.

4. 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 Web SSO on an Unsupported Browser

The expected Imprivata Web SSO workflow on any 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 Confirm ID 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 Imprivata Confirm ID 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 Imprivata Confirm ID 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 details on supported browsers, see Imprivata OneSign 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 unsupported browsers;
• On workstations where the Imprivata agent is not present or unavailable;
• For applications not enabled for Imprivata Web SSO;
• For OIDC applications that track the RP session with a persistent cookie.

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 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 Users > Workflow Policy.

2. On the Confirm ID 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)

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 accepts the push notification, they are given access to the application/resource.

   When authenticating to some sites, the user may need to manually enter the six-digit Token Code from Imprivata ID app.

   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.

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 icon > Web 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.