This release extends the functionality of the authentication client creation. Now you can create OAuth2 authentication clients right from the recipe activation page.
This specific improvement addresses the issue when the UI would not show more than 20 workspaces in the invitation drop-down. Now loader would appear in case you have more than 20 workspaces. Eventually the list of all workspaces would be presented in the drop-down list.
Please Note: only workspaces you have access to (permission
workspaces.workspace.edit) will be loaded.
If your component is written in Java then you can now disable the dynamic
flow control in the step by setting the ELASTICIO_AMQP_PUBLISH_CONFIRM_ENABLED
environment variable in the component repository as false. This is only possible if your component is using the latest Java sailor version 3.3.5.
With this release we introduce initial support for SAML2 SSO Client. To support multi-tenancy, each Tenant has to upload their own service provider configuration for SAML 2.0 provider.
When a user clicks on the button in UI e.g. “Login with Facebook” a popup window
is opened with the target URL /saml/authenticate?providerId={providerId}. Backend
gets the provider from database by providerId for the requested tenant, constructs
service provider interface using saml-js library and redirects to the correct
auth URL(assertEndpoint or /saml/callback?providerId={providerId} if first
is not specified) of the SAML provider.
Then normal SAML 2.0 flow is taking place. In the end, the backend gets info
about the user and tries to find in its DB. If the user is not found, a user is
created on the fly (that is if auto_create_user is true in provider configuration)
using the given user data and temporary password, which could be changed later
on the profile page. After that, a new session is started and the user is being
redirected to the application itself.
If it is a new user then first_name and last_name will be taken from the
similar fields of the SAML 2.0 response attributes.
New frontend endpoints are introduced:
/saml/authenticate?providerId={providerId}/saml/callback?providerId={providerId}New DB tables:
SAMLProvider, more information form the API-docsSAML Identity. This table is using to connect the user with the provider. The record has two relationships user
and SamlProvider. It has also an attribute called is_new_user that hold the record in case when the user was not registered in our system, before logging in using SAML 2.0. Service provider.With this release we introduce new parameter api_docs_url to the tenant
configuration and a capability to manage and redirect visitors to the correct
API-documentation version. This is particularly useful in multi-tenant, white-labelled
environment where each tenant would have a unique api address.
To benefit from this new parameter you must set the api_docs_url parameter and
its value to the tenant record:
api_docs_url is set in the tenant record, every link to the API documentation will be redirected to the provided address.api_domain, then api_docs_url property won’t work correctly for any of these domains. Use api_docs_url only for tenants with unique api_domain.api_docs_url (default is https://[tenant.api_domain]/docs) in tenant.api_docs_url, you will get a redirect loop.selectModel was malformed due to 3rd party host issues.3.3.2.2.6.24.Bulk Extract trigger with incorrect trigger behavior with a large number of retrieved objects.3.3.2.mutlipart/form-data header processing.As a part of the component code audit we updated the Node.js Sailor version to 2.6.24 in the following components: