Single Sign On/Federated Auth

Many enterprises or organizations may wish to manage credentials and security settings (e.g. password complexity, expiration, ip address restrictions) within their own infrastructure to leverage existing identity stores and policies within the organization, typically a Microsoft Active Directory.

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 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 Tidepool according to their role.

Example Authentication Flows

Tidepool Authentication

Federated Authentication and Authorization

Setup flow

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

   1. initial discussion and requirements gathering

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

3. Organization and Tidepool Agree on timeline and ensure changes 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 off boarding users.

• Organization will define manage security settings such as:

  • 2-Factor or Multi-factor authentication

  • Organization 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

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