SSO Integration Overview

Content

This document provides an overview of the LDAP and SAML functionalities and outlines the specific areas of the implementation process that differ from the baseline for clients that have opted for Single Sign On (SSO) integration.

1 SAML

PolicyManager™ is configured to act as the Service Provider (SP) in the SAML authentication process. The user will click a special link or desktop icon that directs them to the Identity Provider (IdP) where their credentials are verified. If the user is verified by the IdP, their browser is redirected to the application with a SAML message that indicates to the SP that the user has been verified by the IdP and should be granted access to the application and thus bypassing the login process altogether. The SAML message sent to the SP by the IdP also contains user attribute information such as first name, last name, site, etc. This information is synced to the user’s account within PolicyManager™. Once again, it is important to note that PolicyManager™ does not store any login information of the user.

It is important to note that if you choose to go with SAML you will also be required to manage your PolicyManager™ users’ departments and profiles through SAML and not through PolicyManager™. This means that you will need to have a resource involved with the project that is familiar with SAML, your identity management scheme and the data that feeds into SAML. They should also be able to help you maintain/modify these SAML rules and configuration moving forward.

IdP-Initiated Login

In this scenario, the user clicks on specialized links (on their desktop, an intranet portal, etc.) to the SP. This requires them to first login to the IdP which then redirects the user to the SP. This generally takes the following format:

1. The user is required to supply credentials to the IdP.
2. A local logon context is created for the user at the IdP.
3. The user selects the PolicyManager™ link.
4. This causes the IdP to generate the SAML Response.
5. PolicyManager™, as the SP, consumes the response via its Assertion Consumer Service.
6. PolicyManager™ allows the user access to the application.

SP-Initiated Login

In this scenario, the user attempts to access the application directly. The application will then redirect the user’s browser to login to the IdP before being redirected to PolicyManager™:

2 LDAP

LDAP authentication is performed by having the user supply their credentials to the PolicyManager™ application. PolicyManager™ is configured to point to a client’s Active Directory (AD) server within their own network. This connection is generally secured via a VPN tunnel.

The user arrives at the PolicyManager™ homepage either by clicking a desktop icon, selecting a bookmark in their web browser, or directly typing the URL. They log into PolicyManager™ with their Active Directory/LDAP credentials.

The application recognizes that this is an SSO via LDAP login attempt and sends the request to the Authentication Server. The request contains all necessary login information regarding the user and which client the user is connecting from. The Authentication Server then performs a bind and the Domain Name(DN) is used to request 3 pieces of information: first name, last name, email address. This information is synced from the AD to the PolicyManager™ database (NOTE: the user’s password is never saved to the PolicyManager™ database). The client’s LDAP server (Active Directory) determines if the credentials match and return a success/fail message. The user is granted access to PolicyManager™ upon receipt of a success message.

Once LDAP is turned on you will make a choice as to whether or not you will use LDAP for only its single-sign-on capabilities or if you want to turn on LDAP rules and also manage your PolicyManager™ user’s departments and profiles through your active directory. For the latter option you must have a resource who understands LDAP, LDAP queries, a solid understanding of your Active Directory structure, and who will be part of the implementation process.

Please note that with LDAP turned on, any user not in your Active Directory will not be able to log on. They will only be able to access the system as an anonymous user.

Implementation

Usernames

The implementing team on the client side should request from their IT team the usernames for users that they are submitting to the PolicyMedical team for upload into the application. This will ensure that once the SSO integration is completed that users will not have a new account automatically generated due to a difference in the username they have in PolicyManager™ and the username they have in their own AD. This applies when providing System Administrator as well as Power User usernames.

User Management via SSO Import Rules

PolicyManager™ includes a feature called “Import Rules” which allows users that match preset rules to be automatically assigned a Profile, Department(s), and Committee(s).

The rules are based on the fields present within an Active Directory system. For example, an AD may have a field that maps a user’s department to a number (say ‘Nursing’ to 1000). An Import Rule can be created that assigns all users with that department’s number a specific Profile and Department. The benefits are obvious here – one rule manages the access level of an entire department. There is no need for the administrator of the application at the client facility to select each user one-by-one and assign their Profile and Department(s).

Where this feature really shines is when dealing with new hires or people who have changed roles. When properly set up, Import Rules could be set up to manage all users within a facility. Then, when the Active Directory is updated to reflect an existing employee’s new role or a new employee, their access levels would be defined by the Import Rules when they log-in to PolicyManager™.

A user can validate against multiple rules as well, which is where the flexibility and depth of the Import Rules feature are displayed. Import Rules can be set up to be as complex or as simple as needed depending on the facility’s needs.

NOTE: LDAP Import Rules are completely optional whereas SAML Import Rules are mandatory.