SSO/Single Sign On/Federated Authentication and Authorization

Tidepool supports enterprises or organizations that may wish to manage credentials and security settings (e.g. password complexity, expiration, ip address restrictions) within their own infrastructure to fulfill compliance needs and local requirements, leverage existing identity stores and policies within the organization.

After Tidepool applies an SSO configuration for an email domain, recognized log-in attempts will redirect the user to sign in with their Clinic credentials, so long as the user was added to the appropriate AD group(s), they will authenticate appropriately and successfully access Tidepool.

Note: There is a user invite process within the Tidepool application that assigns either Clinic Member or Clinic Admin permissions, managed by someone with Clinic Admin permissions in the application. 

Open

Sample SSO configuration with Azure ADFS (simplified diagram)

Tidepool has implemented Keycloak, an Open Source identity broker supported by Red Hat and deployed and managed by Tidepool in Tidepool’s AWS cloud to integrate enterprise login services.

Using Keycloak allows Tidepool to support multiple identity providers agnostically for the individual organizations allowing them to maintain complete control over users and support them in maintaining a single source of truth for login.

Keycloak functions as a Service Provider which allows Tidepool to integrate with enterprise Single Sign On services running SAML or OpenID to federate authentication and authorization.

After integrating with Keycloak, when a clinician or other organizational user logs into Tidepool with an internet domain that has been federated, instead of authenticating with a username and password to the Tidepool User Store, Tidepool will redirect logins for that domain to the organization's user store (called an IdP, or Identity Provider) using the SAML or OpenID Connect protocols supported by nearly all Identity Providers as Open Standards, though there are differences in functionality, behavior and configuration among each IdP.

Once an identity has been verified with the IdP it provides a token to Tidepool’s Keycloak instance (the SP or Service Provider) that authenticates and authorizes the user to use Tidepool according to their role.

Authentication flows

SAML Federated authentication flow

Open

ref: https://en.wikipedia.org/wiki/File:Saml2-browser-sso-redirect-post.png
CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=111140695

OpenID Connect authentication flow

Tidepool Keycloak setup flow

1. Organization contacts clinic@tidepool.org to initiate discussion

   1. Schedule a call with organization IT/Security staff for initial discussion and requirements discovery

2. Tidepool meets with Organization IT staff to discuss details of configuration:

   1. IdP integration

   2. domains and patterns required to authenticate users

   3. process for org integration

   4. timeline and support communications

3. Organization and Tidepool Agree on timeline and ensure changes and notifications are coordinated with clinic and IT staff

4. Tidepool configures Keycloak ↔︎ IdP integration via an exchange of secure tokens and information on how to authenticate organization users. This usually consists of metadata information in a structured file or a URL pointing to an .xml file and exchanging needed service URLs and endpoint information

Differences

• Organization will manage all users and passwords internally and are responsible for onboarding and offboarding users.

• Organization will define manage security settings such as:

  • 2-Factor or Multi-factor authentication (2FA/MFA)

  • Organization level audit logging

  • Password complexity, expiration, aging

  • Login restrictions (ip address, time based, location based)

• If Organization’s user store (AD or IdP broker service) is not accessible, federated users will not be able to login to Tidepool

• Organization domain and login patterns or metadata will be verified programmatically in Keycloak and applied based on policy

Requirements

• Tidepool requires a valid email address to support the Clinic Admin authorization process

• Tidepool Keycloak supports only SP-initiated logons at this time

• SAML 2.0 or OpenID Connect compatible IdP provider

• a domain (e.g. an email domain) or other pattern that can be used to programmatically match logins

Example Identify Providers supporting SAML and/or OpenID

• Microsoft ADFS and Azure ADFS running SAML or OpenID Connect

• Ping Federate running SAML or OpenID Connect

• Auth0 running SAML or OpenID Connect

• Shibboleth

• Google Workspace

More Information on Keycloak, SAML and OpenID Connect