Office 365: Imprivata Web SSO Setup

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

Imprivata: View and Copy IdP Metadata

1. In the Imprivata Admin Console, go to the gear icon > Web app login configuration.

2. Click View and copy Imprivata (IdP) SAML metadata.

3. Copy the IdP metadata XML file. You will need to open and edit this file in the next section.

4. Copy the Entity ID. You will need to enter this value in the next section.

Office 365 Needs Metadata from Imprivata

Imprivata and Office 365 need metadata from each other. Import the relevant metadata to Office 365, and save the application profile.

Office 365 supports entry of the IdP metadata via the PowerShell command line. First, you must install Microsoft Entra ID "cmdlets":

1. Run Windows PowerShell as an Administrator.

2. Run the following command to install the necessary modules:

   Install-Module MSOnline

3. Connect to Office 365:

   Connect-MsolService

4. A Microsoft Sign in window opens. Enter your Office 365 Administrator credentials and click Next.

5. Check the current status of the settings:

   Get-MsolDomainFederationSettings -DomainName YourDomain.com | Format-List *

6. Office 365 requires the IdP Certificate data in a specific format.

   1. Locate the following tags in the IdP metadata:

      <md:KeyDescriptor use="signing"><ds:KeyInfo><ds:X509Data><ds:X509Certificate>

   2. Copy the string of characters between these tags and the closing </ds:X509Certificate> tag.

   3. Remove all spaces and new lines from the string.

   4. In the PowerShell CLI, enter the result inside double quotes as follows:

      $cert = "certificate data"

7. Complete configuring the IdP metadata by entering the Set-MsolDomainAuthentication command twice (once Managed, once Federated)

Windows PowerShell Sample

Windows PowerShell

PS C:\> $domainname = "company-domain.com"

PS C:\> $brandname = "Your company's domain used for Office 365"

PS C:\> $issueruri = "ENTER ENTITY ID HERE"

PS C:\> $passivelogonuri = "ENTER SSO POST URL HERE"

PS C:\> $logoffuri = "ENTER SSO REDIRECT URL HERE”

PS C:\> $protocol = "SAMLP"

PS C:\> $Cert = "ENTER CERTIFICATE DATA HERE"

PS C:\> Set-MsolDomainAuthentication -DomainName $domainname -Authentication Managed

PS C:\> Set-MsolDomainAuthentication -DomainName $domainname -FederationBrandName $domainname -Authentication Federated -IssuerUri $issueruri -LogOffUri $logoffuri -PassiveLogOnUri $passivelogonuri -SigningCertificate $cert -PreferredAuthenticationProtocol $protocol

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

2. Click Add App Profile > Web application using SAML. The Add web application using SAML 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 Get SAML metadata.

5. Select From URL and enter the following Service Provider metadata URL:

   https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

6. Click Import. The Imported Metadata fields are now populated.

7. Click OK.

8. Office 365 requires the following user attributes:

   • NameID — Must be set to the default value of Persistent that as been set by the O365 (MSOL/Azure) Metadata URL.

   • IDP Email — Email is a required attribute for O365 (MSOL/Azure). This attribute is set by default when creating the Imprivata SAML Application profile.

   NOTE:

   Additional attributes maybe necessary for other Azure Applications that are part of the (MSOL/Azure) federation. Contact your application vendor for any specific SAML attributes.

9. Click Save SAML application.

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.

Available Attributes

• Email address (mail)

• First name (givenName)

• Last name (surname)

• Static value:

• User domain

• User logon name (userPrincipalName)

• User logon name - Pre W2K (sAMAccountName)

• User security identifier (objectSID)

• User unique ID (objectGUID)

• User unique ID (UUID)

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

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 Users > Workflow 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)

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.

Optional — Smart Links

Smart links link users directly to applications that support Imprivata OneSign WebSSO.

These URLs send a user through the expected workflows described above, without requiring the user to use the Microsoft Entra ID access panel or Office 365.

Smart link templates for Office 365 applications

Replace YourFQDN with your FQDN:

• The user's Office 365 Apps Portal — https://myapps.microsoft.com/?whr=YourFQDN

• OneDrive for Business — https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=
6%2E1%2E6206%2E0&wreply=https%3A%2F%2FYourDomain-my.sharepoint.com%2F&whr=YourFQDN

• Outlook Calendar — https://outlook.office.com/owa/?realm=YourFQDN&path=/calendar/view/Month

• Outlook Web Access to Exchange Online — https://outlook.com/owa/YourFQDN

• Self Service Password Reset (SSPR) — https://passwordreset.microsoftonline.com/?whr=YourFQDN

• Word Online — https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=
6%2E1%2E6206%2E0&wreply=https%3A%2F%2Foffice.live.com%2Fstart%2FWord.aspx
%3Fauth%3D2&whr=YourFQDN

• SharePoint Online — https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=
6%2E1%2E6206%2E0&wreply=https%3A%2F%2FYourDomain.sharepoint.com%2F&whr=YourFQDN

• Excel Online — https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=
6%2E1%2E6206%2E0&wreply=https%3A%2F%2Foffice.live.com%2Fstart%2FExcel.aspx
%3Fauth%3D2&whr=YourFQDN

• Teams Web — https://login.microsoftonline.com/common/oauth2/authorize?client_id=
ApplicationID&response_mode=form_post&response_type=code+id_token&scope=
openid+profile&redirect_uri=https%3A%2F%2Fteams.microsoft.com&domain_hint=YourFQDN

  BEST PRACTICE:

  The Teams’ smart link is 254 characters long. This is longer than supported by a local shortcut. If you need to provide a local shortcut to Teams Web, use a URL-shortening tool.

Smart Links for Third Party Apps

Smart links for third-party apps can have two formats. Choose the format that works for your app.

The smart link requires the following:

• Third-party app name
• Application ID
• Your FQDN

Examples (replace the bold text):

• https://myapps.microsoft.com/signin/AppName/ApplicationID?whr=YourFQDN
• https://myapps.microsoft.com/YourFQDN/signin/AppName/ApplicationID

Third Party Application IDs

To view Application ID for a specific application:

1. Sign in to your Office 365 account.

2. Go to https://portal.azure.com/. You should be signed in as your Office 365 user.

3. Go to Microsoft Entra ID > Home > Enterprise applications - All applications.

4. Click the name of your added application.

5. Go to Manage > Properties.

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.

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