Skip to main content

New features specific to SaaS

This page cumulates all the new ThingPark Enterprise features brought by the different 8.0.x software releases, which are specific to SaaS (i.e. not applicable to Self-hosted deployments). See the 8.0 changelog to know more about the split of those features per maintenance release.

Federated authentication RDTP-17092

This feature allows ThingPark Enterprise SaaS subscribers to delegate the authentication of their end-users to third-party identity providers, to support federated authentication and single sign-on (SSO) across the user's different applications.

For self-hosted ThingPark Enterprise, the delegation of end-user authentication is already supported since release 7.1. To learn more, see RDTP-17071.

Federated authentication relies on OAuth2 OpenID Connect authorization code flow.

Prior to release 8.0: all SaaS users authenticate using credentials that are managed by ThingPark's embedded identity provider (Keycloak).

Starting release 8.0: ThingPark SaaS subscribers may request the authentication delegation of some/all their end-users to a third-party identity provider (IdP).

  • The delegation is fully based on the domain name of the user's email address.
  • It is possible to have, in the same subscription, end-users delegated to different identity providers, as well as local users.
    Example Within the same subscription:
    • end-users having their email address xxx@domain1.com may be delegated to IdP1,
    • while other end-users with email address xxx@domain2.com may be delegated to IdP2,
    • and those with email address xxx@domain3.com remain handled by ThingPark's embedded IdP without delegation.

When authentication federation is enabled, user accounts must still be provisioned in ThingPark to define the roles and permissions assigned to each user.

More details

In federated authentication, only the end-user's email is known to ThingPark, the password is known only to the federated IdP. Hence, ThingPark's password recovery procedure cannot be used for federated users.

To allow federation discovery based on the email, the login form is separated into two stages:

  1. In the first stage, the user is asked to type his email address only:

  2. Then the user is either redirected to a federated identity provider or to ThingPark's local login + password form.

The authentication status of each end-user is displayed in ThingPark's user interface:

  • INVITED: The user has been invited but has not yet logged in.
  • FEDERATED: The user's authentication is delegated to an external identity provider.
  • LOCAL: The user's authentication is locally managed by ThingPark.

note

When the federation is disabled for an email address domain, all the associated users must migrate from federated to local password: each user must perform a "Forgot password" procedure to create a local password.

Key customer benefits

This feature allows easier ThingPark integration with the customer's IT services to offer a federated authentication with Single Sign-On (SSO) user experience across all the customer's applications managed by their identity provider.

Additionally, with the delegated authentication, the customer may freely define the end-user authentication policy, such as password storage and enforcement rules, without any dependency on ThingPark.

Feature activation

This feature is deactivated by default, which means that all the end-users remain managed by the local identity provider after upgrading to release 8.0.

Contact your ThingPark support team if you want to activate it. Activation steps can only be executed by the platform administrator.

Feature limitations

  • Only delegation based on OpenID Connect protocol is fully supported in this release. Delegating authentication to external identity providers using SAML protocol has not been tested in this release.

  • After delegating an email address domain, existing end-users using this same domain will appear as non-federated until their next login attempt to ThingPark.

Support public connections predefined by Actility RDTP-11865

A new type of connections is supported starting release 8.0: it corresponds to public connections that are made available by Actility to all the SaaS customers.

For instance, this is relevant for Abeeway devices that use the ThingPark X Location Engine (TPX-LE): in this case, the new predefined public connection becomes ready to use for all the TPE-SaaS subscriptions without prior configuration by customers.

More details

Public connections are displayed with this logo:
They are already pre-configured by Actility and are ready to be used by TPE users to associate them with their devices and multicast groups.

Key customer benefits

Better user experience, simplifying the use of global connections such as the ThingPark X Location Engine.

Feature activation

Public connections are predefined by Actility. They cannot be created by TPE users, who can access them in read-only mode and associate them with their devices and multicast groups as needed.

Feature limitations

Not applicable.