Skip to content

Auth Clients and Single Sign-on

PHC allows you to configure third-party authentication clients for Single Sign-on (SSO). This makes the login process easier and frees you from having to create usernames and passwords for new PHC users. It also provides an extra layer of security for an organization's account.

PHC offers preconfigured options to set up Facebook and Google authentication as identity providers. It also offers a Custom Identity Provider option that allows you to set up a wide variety of SSO providers.

PHC supports the SAML 2.0 protocol. Only SP-initiated SSO is supported. IdP-initiated SSO is not supported.

!!! note The Auth Clients tab is only available for Enterprise account customers. The tab does not appear at other account levels. To become a LifeOmic Enterprise customer, contact your LifeOmic representative.

Configure an Authentication Client

!!! caution Configuring an SSO client is an advanced operation. Assistance from LifeOmic is available.

!!! access-control "Access Control" A user needs to belong to the default Admin group or have those permissions to complete this procedure. To add a user to the default Admin group, complete the Add a user to a group with the Users tab procedure.

  1. From any page in PHC, click the PHC logo at the top of the page.
  2. From the home page, click the Account Info tile. Account
  3. From the account info page, click Auth Clients to see the currently configured Authentication Clients.
  4. If you need to delete an existing client, click the icon next to the client name.
  5. To add a new client, click New Client. You are allowed one Web Client and one Client Credentials. Account
  6. Enter a name in the Name field.
  7. The Callback URL(s) and the Logout URL(s) populate automatically.
  8. Under Allowed OAuth Flows, click Web Client. Note: Client Credentials is not normally used. If you need programmatic interactions with PHC, the best practice is to create an API key. For more information, see API Keys.
  9. Click one or more Allowed Identity Providers:
    • Google allows you to use Google IdP as a SAML identity provider.
    • Facebook allows you to use the Facebook Login feature for an authentication method.
    • LifeOmic is reserved for LifeOmic employee use.
    • Custom Identity Providers allows you to configure a variety of SSO clients, such as Microsoft Azure. See the following section, Configure a Custom Identity Provider, for detailed information on this option.
  10. An Alternate OIDC Providers is usually not required. An Alternate OIDC Provider is required for use with SMART on FHIR applications. See below for more information on alternate OIDC providers.

  11. Click Save Changes. Account

Configure a Custom Identity Provider

The information needed for a custom identity provider is specific to that provider and is normally publicly available. For example, when you want to configure Microsoft Azure, consult the Microsoft Azure documentation to find the necessary information for the fields in the SSO (Single Sign-On) section of PHC.

Example Configuration for customer123 Account

This example is for an organization leveraging Shibboleth IdP

  • Callback URLs: https://apps.us.lifeomic.com/auth/v1/app-redirect
  • Logout URLs: https://customer123.apps.us.lifeomic.com/phc/logout
  • Metadata document URL: https://customer123.idp.example.com/shibboleth-idp/shibboleth
  • Email attribute mapping: urn:oid:0.9.2342.19200300.100.1.3
  • Name attribute mapping: urn:oid:2.16.840.1.113730.3.1.241

Example User/Browser Flow

In addition to the diagrams below, you can also reference the AWS Cognito documentation.

SSO Flow

Example URLs and parameters, using Okta for the IdP:

SSO Flow URLs

Configure an Alternate OIDC Provider

Configuring an alternate OIDC provider is used to link identities from an external Open ID Connect (OIDC) provider to PHC users. Once an OIDC identity has been linked to a PHC user, the user will no longer need to login to the PHC when they have previously authenticated with the OIDC provider. Typically this is used in our SMART on FHIR app so that EHR users don't have to login to the PHC when they launch the app. To configure the alternate OIDC provide you will need to specify the following:

  • Name: a name you want to use to identify the provider
  • Client Id: the OAuth2 client id for the parent application that authenticates with the OIDC provider. For Cerner EHRs this will be a UUID and can be obtained from Cerner.
  • OIDC Issuer: the OAuth2 issuer URL for the provider. For Cerner EHRs this will be of the form https://authorization.cerner.com/tenants/TENANT_ID/oidc/idsps/TENANT_ID/ where TENANT_ID is the ID of your Cerner tenant and can be obtained from Cerner.
  • Jwks URL: A URL that can be fetched to get the JSON Web Key Sets for the provider. For Cerner EHRs this is https://authorization.cerner.com/jwk

Linking OIDC Subjects to PHC Users

After the alternate OIDC provider has been configured, then any of our applications that run in the context of the OIDC provider (e.g. our SMART on FHIR app) will prompt the user for a password on first use, and then will link their OIDC user to the PHC user automatically so they will not have to log in to the PHC on subsequent uses of the application.

An administrator that has both Account and Access privileges can also manually link an OIDC user to a PHC SSO user so that the OIDC user will never have to log into the PHC. To manually link an OIDC user follow this procedure:

  1. Hover over the provider row and then click the icon to bring up the list of linked users.
  2. Click the Link New Identity button.
  3. Enter the user's OIDC username (e.g. EHR username) in the OIDC User Name field.
  4. Enter the user's PHC SSO username in the PHC User Name field. If you don't know the user's PHC username then you can use the PHC User Search field to find it. PHC SSO usernames will usually be of the form accountid_person@yourdomain.com where accountid is the ID of your PHC account, and person@yourdomain.com is the user's email address. The exact format of the username will vary depending on the SAML provider that is being used.

Last update: 2021-08-04