v0.40 — November 24 2023

SSO Authentication (Beta)

SSO Authentication allows for you to bring your own identity provider (IdP) to facilitate authentication in ZapEHR. With SSO, when Users visit your application, they will be prompted to log in not with ZapEHR email/pw connection credentials, but with a familiar login screen from your own IdP. For example, this might be an Azure AD or Okta Workforce login screen. Users complete authentication with your IdP, it redirects back to ZapEHR's auth, and the rest of the authorization code flow completes as usual.

One of the big perks of SSO is that if the User is already authenticated with your IdP before visiting your ZapEHR application, they will automatically be authenticated without needing to enter their credentials again.

When Users log into your ZapEHR Application for the first time using SSO, they are granted a default Role you specify during SSO configuration. Depending on your use case, this might grant no permissions or somewhat broad permissions.

During the SSO authentication, User data from your IdP is stored in ZapEHR. It is made available in the GET User endpoint, so you can use it to implement your business logic. For example, you might want to grant a certain Role in ZapEHR to Users from your IdP that have a custom claim proving that they are a provider or administrator.

SSO Authentication supports all major SSO Identity Providers as well as the OpenID Connect Protocol and SAML.

While SSO Authentication is in beta, there is a limited amount of configuration necessary by the ZapEHR team. Reach out by email ([email protected]) to get stared with SSO Authentication.

Additional changes

• Fixes for a few constraints which were not being enforced correctly in FHIR R5.
• Developer Console — Improved the workflow for assigning and removing Roles from Developers, Users, and M2M Clients.