CareAR Assist - Version: 23.02 – CareAR Help Center

Release 23.02 of the CareAR Platform delivers the following:

SSO Support (SAML 2.0)
Minor UX Updates
- Local feedback when host or a collaborator uses the pen annotation tool
- Main contact list includes the ability to set/unset favorites
Minor Security Updates
Minor software library and SDK updates

New Features

SSO Support (SAML 2.0)

Single Sign-On (SSO) provides numerous benefits to the end user, including fewer credentials to manage, simpler login, and better productivity. The benefits to the organizational IT sponsor are numerous: improved security, consistent and streamlined user management, as well as unified credential policy (strength, aging policy, reset flow, etc).

The purpose of this feature is to enable the first phase of support for SSO for the CareAR SXM platform and CareAR applications. We will focus initially on supporting SAML 2.0 based Identity Providers.

The high-level scope of our first phase of SSO support includes

just-in-time provisioning;
authentication;
authorization (including role definition); and
formalization of the primary tenant administrator.

Primary Tenant Administrator

In our current support of the CareAR administrator role, we have an implicit primary administrator; this role is the first administrator (and first user) that is created when we create a new CareAR tenant.

We will formally and visibly indicate this role in the Administration screen where today it appears as “Tenant Admin.” The new label in the Administration screen shall be “Primary Tenant Administrator”.

By default, the initial administrator (the person identified when creating the tenant) will take on the formal role of primary administrator. We will only allow a single primary administrator. The primary administrator is ineligible to use SSO and will always authenticate locally in Firebase.

SSO Configuration Flow

The high level flow of enabling SSO on a CareAR tenant consists of three steps as described below.

Our focus with this feature is on step 2 and step 3. The details of step 1 are outside the scope of CareAR and should be documented by your IdP provider.

Once the SSO settings are configured and enabled, users who are tagged as CareAR users (in the IdP domain) will use their SSO credentials to authenticate with CareAR; local firebase credentials (i.e., local password), should they exist, will not be used to authenticate a user. The first time a user logs into CareAR using SSO, the CareAR system will provision the user into the tenant in a just-in-time fashion.

Note that once a tenant has been setup and enabled for SSO, we will not support a mix of authentication methods for the users excepting the primary administrator.

We have implemented an entitlement flag that controls, on a per tenant level, whether SSO is visible to the tenant administrator. By default, this flag is set to disabled. CareAR Operations will enable this flag for any customer wishing to have the SSO functionality visible.

Just-in-time Provisioning

Once SSO is enabled, the IdP Service will provision users based on the user data that is implemented in the IdP Service domain. When a user attempts to log in the first time, the SAML 2.0-based SSO function will transfer the user attributes to CareAR infrastructure, which will in turn write them to the user database of the CareAR tenant. In this way, users will be provisioned into the CareAR tenant at the time when they first log into the system (app or portal). We will refer to this as just-in-time provisioning, as opposed to provisioning that happens prior to (and independent of) the user logging in.

The user attributes stored in the IdP domain include:

email
first name
last name
primary phone number
secondary phone number
job description
role
CareAR group assignment

Unless a user’s role is “primary tenant administrator,” then the user attributes will be viewable only within the CareAR portal. Changes to these fields must be made at the IdP Service, which serves as the source of truth. We will not permit user attributes to be edited in the CareAR portal, except for the primary administrator.

If the tenant plan is user-based, then the Licensed Subscribers quantity will be the maximum number of users (minus 1 for the primary administrator) that will be able to be provisioned. Under no circumstance will we permit JIT provisioning to override this maximum cap of allowed users. For usage-based service plans, then the JIT provisioning will have no maximum cap.

The consequence of this approach is that every time a user authenticates using SSO, any changes to the user attributes (excluding email) will be overwritten in the CareAR user record (i.e., the user document in FireStore and the custom claims in firebase admin database). Through this procedure, over time the user entries will be updated with user attributes sourced from the IdP Service.

Disabling Users

When a tenant has SSO enabled, we will continue to allow tenant administrators (and the primary administrator) to disable a user using the CareAR portal.

Deleting Users

When a tenant has SSO enabled, we will continue to allow tenant administrators (and the primary administrator) to delete a user using the CareAR portal.

Reset Password Flows

With SSO, all the password recovery and reset operations occur outside of the context of CareAR. So, when SSO is enabled, the reset password link in the portal will be visible but disabled for a non-administrator user. (Remember that the primary administrator role is not eligible for SSO, uses local firebase credentials, and may need to reset their password from time to time.)

Backward compatibility

No backwards compatibility will be supported. We expect that tenants with SSO enabled will require their users to be running release 23.02 of the CareAR app.

Mac OS App Support for Apple's M1/M2 Processor

This release provides support for Apple’s M1/M2 processor in the macOS app. It is supported in the same application executable.

Minor UX Updates

Prior to release 23.02, when the host or collaborator annotates on the live video feed using the pen tool in the mobile app, live feedback was not provided which may lead to a poor user experience. The user experience sequence was as follows:

Local Feedback for Pen Annotation in mobile app

Collaborator draws with finger or stylus
Collaborator lifts finger or stylus
Annotation details sent to streaming party
Streaming client composites and sends to cloud
Cloud distributes to all participants
Only when annotation received by collaborator does he/she the annotation

With release 23.02 of the mobile app, we now provide dotted line feedback locally to the collaborator in real time prior to distribution to all participants. The final annotation is then distributed per steps 1-6 above.