Single Sign On

The Azure SSO login mechanism

What does it do?

We have added a sign-in button to the login page of the web app. This enables caregivers that have a Microsoft email-address to log in to the web app with a new login mechanism. The identity of the user will be checked by the identity provider of your organization. They can define requirements for logging in, such as using 2-factor authentication, fingerprints, hardware tokens. It gives organizations more control over the login mechanism. The browser will remember the users’ Microsoft account, and depending on the Active Directory settings at the hospital, users will be able to quickly log in again after they are logged out.

The Azure SSO login mechanism will exist next to the existing login functionality, with One-time passwords and optional 2FA with a password.

 💡 Note, this is a different single sign on method than how the viewer works. The technologies and the ideas are similar, but they are not interchangable. The viewer SSO mechanism links users from an EMR to users in Luscii, enabling EMR users to easily open the Luscii viewer after an initial login. The Azure Single sign on method offers a different way for a user to log in to Luscii.

What are the limitations?

  • This functionality is only available for healthcare professionals.
  • The organization must be managing their users in Azure Active Directory. This is a service that quite a lot of hospitals use.
  • There is no synchronization between users in Azure Active Directory and Luscii. Administrators will still need to create a Luscii user, and remove the user in Luscii once someone leaves their organization.
  • The functionality will not be turned on for the viewer integration and the iOS pro app.
  • The Microsoft email address must be the match the email address for the user in Luscii.

When

We want to make this functionality available in the beyond app on September 11 (after the current dev cycle)

What is next?

We will be gathering feedback from customers about this functionality and what we should build next for Single Sign On. A few things we are currently thinking about:

  • Enabling the functionality in the viewer integration
  • making it possible to disable the traditional login method for users of a customer, so they must log in through the customers’ azure AD identity provider
  • Setting up user synchronization between active directory and Luscii (SCIM)
  • Role authorization for synchronized users
  • Enabling more Single Sign On flows, such as Google