Release 23.02 of the CareAR Platform delivers the following:
- SSO Support (SAML 2.0)
- Experience Builder
- iFrame Element
- Open Search Results in New Tab
- AI Platform
- Nested Sitemap Support
- Cancel Indexing
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)
- 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:
- 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.
Configuration Parameters
The following configuration parameters serve as a guide for setting up SSO. Additional details relating to setup and provisioning of SSO are available on the CareAR help center.
|
Service Provider Attribute Name |
IdP Attribute Name | Mandatory/Optional | Comments |
| role | role (user custom attribute) | optional | Allowed Roles : tenant_admin, creator, analyst and user. For SSO user If role not matched with the above or absent we treat the role value as “user”. |
| tenantId | tenantId (user custom attribute) | mandatory |
Must be a CareAR tenantId. Field name (“tenantId”) not case sensitive; field value MUST be case sensitive. |
| firstName | firstname | mandatory | Supports Unicode characters + English characters. Min 2 Len. For SSO user, Stripping the numbers if it has. |
| lastName | lastname | mandatory | Supports Unicode characters + English characters. Min 1 Len. For SSO user, Stripping the numbers if it has. |
| primaryPhone | phoneNumbers.mobile | optional |
|
| secondaryPhone | phoneNumbers.home | optional |
|
| group | group (user custom attribute) | optional | group value must exist in tenants group list, if not keeping null/ empty. For SSO user the group must match with the tenant's groups list, if not keeping null. |
| jobDescription | description | optional | String content |
Experience Builder
iFrame Element
Third party web pages can now be embedded into experiences by using the iframe element. The iframe element can be added to any page and resized vertically to occupy the desired amount of the page. When entering the address for a third party web page, it will be displayed within the iframe area that was created within the Experience Builder. All URLs used with the iframe element must contain a URL with “https://”. The web page you wish to embed must also allow it to be embedded within an iframe. Check the web pages security settings if it does not display properly with the experience iframe element.
Open Search Results in New Tab
Content creators can now customize how Intelligent Search results are opened. In the search settings found in the experience launch page properties window now include the option to open search results in a new window. When enabled, if a user selects a search result from a search query, it will open the resulting page in a new browser tab instead of within the same window.
AI Platform
Nested Sitemap Support
Some websites contain several sitemaps with a top level sitemap of other sitemaps. When creating an Intelligent Search index via the XML sitemap method, you can now provide the URL to the top level sitemap. When Intelligent Search starts generating the index it will follow the links in the top level sitemap to the children sitemaps and index all pages contained in the sitemap.
Cancel Indexing
When creating a search index of via the XML sitemap method you can now cancel the indexing process if you which to stop the process.