August 30, 2023

Highlights

Provision Users Just-In-Time

We’re thrilled to announce the introduction of our Just in Time (JIT) Provisioning feature to Cloudentity. This feature transforms the landscape of user management and authorization capabilities, particularly when integrating with external Identity Providers (IdPs).

Our JIT Provisioning feature enables a unified user representation by centralizing and tracking all users, regardless of the authentication source. It enriches user profiles by augmenting attributes with additional identity-related data stored locally. Crucially, it also captures operational attributes such as the last authentication time for all users, maintaining an accurate and updated record of user activity.

What sets this feature apart is its capacity to facilitate persistent user records within the Cloudentity system for users originating from external IdPs. This not only involves creating a persistent identity but also manages the lifecycle of user attributes, thereby providing a more detailed and up-to-date user profile. This comprehensive view of user attributes greatly enhances our access management and authorization decisions.

Our new capabilities include a selection between auto-provisioning and manual provisioning modes for user access, defining a persistent store for user lookups and provisioning, setting criteria for matching external IdP users with internal system users, and automating user data addition to the local identity store using an attribute mapping feature.

The JIT Provisioning feature is a significant stride towards a more efficient and effective user management process. As we continue to improve and expand our offerings, your feedback is invaluable in helping us better serve your needs. Please note, we are currently in the MVP (Minimum Viable Product) stage, with more enhancements planned for future releases.

Breaking Changes

[ AUT-8951 ] We have removed the single_sign_on feature flag at the tenant level, making Single Sign-On (SSO) universally available to all tenants. However, it’s important to note that SSO must still be activated at the server level. Administrators retain the capability to enable or disable SSO at the server level as needed.

Due to the SSO being enabled, we removed the previous Authentication Context Caching functionality as peristent user sessions can be achieved using more advanced SSO. If you cached the authentication context, switch to SSO.

[ AUT-9161 ] We’ve adjusted the default logout redirect path. Previously set to /app/<tenant>/<workspace>, it has now been changed to /<tenant>/<workspace>/app. The former sequence, with /app positioned at the beginning, was found to be directing users to an invalid location. This updated configuration ensures users are redirected to a valid login page post-logout.

[ AUT-9760 ] The FDX DCR feature flag has been removed. Moving forward, the registration_endpoint will direct to /fdx/dcr/register, superseding the previous /oauth2/register path. This streamlines the registration process and provides a more consistent endpoint structure.

Deprecations

[ AUT-9703 ] Added introspection endpoint for Open Finance v3 payments located at POST /open-banking-brasil/open-banking/payments/v3/consents/introspect. This endpoint is backwards compatible and can be used to introspect previous versions as well.

Older iterations of this endpoint POST /open-banking-brasil/open-banking/payments/v1/consents/introspect and POST /open-banking-brasil/open-banking/payments/v2/consents/introspect have been marked as deprecated.

[ AUT-9707 ] Deprecated the following Identity Pool APIs:

• Self Get User Profile

• Selft Update User Profile

Instead, OIDC-compliant userinfo API should be used to get information about the user, and the System Level Identity Pool Users APIs for backend applications should be used to update the user’s data.

Major Additions and Changes

[ AUT-8086 ] Added Just-in-Time User Provisioning. For more, see the highlights.

[ AUT-9700 ] Update Identity Pool IDP creation flow.

Minor Enhancements

[ AUT-6868 ] We have introduced the auth_time attribute within the authentication context. This inclusion facilitates mapping to the AT claim, enabling support for the Max Age step-up process. This enhancement ensures a more granular control and improved security measures during authentication sequences.

[ AUT-9331 ] If JIT is enabled and points to administrator identity pool, it’s possible to grant roles to provisioned users.

[ AUT-9395 ] We’ve enhanced the user experience in the extensions editor. Users can now dynamically resize the editor window and the associated bottom panel, offering improved flexibility and a tailored view to suit individual preferences..

[ AUT-9415 ] In our commitment to bolster security configurations, we’ve integrated a new Upload PEM File field within the server client’s OAuth settings. When users provide a PEM certificate through this field, it will be parsed and utilized to streamline the configuration process for both self_signed_tls_client and tls_client authentication token methods. This ensures a more intuitive setup while reinforcing secure communication standards.

[ AUT-9421 ] Improved product UI scaling across multiple devices.

[ AUT-9509 ] To enhance workspace management capabilities, we’ve introduced a new POST /{tid}/workspaces/{wid}/promote/config-clone API endpoint allowing for the cloning of an existing workspace within the same tenant.

Please note that this API is an alpha feature available for testing and initially hidden. It can be accessed once the tree_dump_tenant feature flag is enabled. This allows for controlled deployment and evaluation of the feature.

[ AUT-9512 ] We’ve introduced a suite of system-level APIs for robust organization management:

• GET /organizations: Retrieve a list of all organizations.
• POST /organizations: Create a new organization.
• DELETE /organizations/{wid}: Delete a specified organization using its workspace ID.
• GET /organizations/{wid}: Retrieve detailed information about a specific organization using its workspace ID.
• PUT /organizations/{wid}: Update details of a specified organization using its workspace ID.

These new system-level endpoints operate identically to their counterparts found within the admin APIs.

To access and utilize these system-level APIs, a token issued by the system workspace is mandatory. Additionally, this token must possess the manage_organizations scope, ensuring that only authorized users with the right privileges can manage organization details at the system level.

[ AUT-9541 ] We’ve introduced the ability to invite Workspace Administrators.

By utilizing this feature, tenants can now:

Efficiently manage and distribute administrative duties within their workspace. Delegate specific tasks and responsibilities to specialized administrators. Achieve greater flexibility in defining access controls and permissions. This proactive approach not only optimizes the administration process but also empowers tenants to craft a more tailored and efficient workspace management strategy.

[ AUT-9542 ] Feature Update: Workspace Role & UI Adjustments

• Assign workspace roles during administrator creation.
• Manage user roles in the user details view.
• “Users” and “Settings” now in separate navbar sections.

[ AUT-9555 ] We’ve introduced APIs for ‘authorization details’, an entity from the OAuth RAR spec. These support actions like create, get, update, delete, and list. Admins can define multiple authorization details in a workspace, each linked to a service and having a unique type. A schema is required for every detail. This feature is currently under a feature flag. Additionally for every authorization detail schema must be defined, for example:

{

"type": "payment_initiation",
   "locations": [
      "https://example.com/payments"
   ],

"instructedAmount": {
      "currency": "EUR",
      "amount": "123.50"
   },
   "creditorName":
"Merchant A",
   "creditorAccount": {
      "bic":"ABCIDEFFXXX",
      "iban":
"DE02100100109307118603"
   },
   "remittanceInformationUnstructured": "Ref Number
Merchant"
}

A minimal schema must have at least a type property:

{
  "properties":
{
    "type": {
      "description": "type",
      "type": "string",
      "minLength": 1

}
  },
  "description": "basic user data",
  "type": "object",
  "required": [
    "type"

]
}

[ AUT-9556 ] The well-known endpoint now has the authorization_details_types_supported attribute showcasing registered authorization detail types, accessible behind a feature flag.

Additionally, there’s an advanced configuration to disable RAR, available via API. When disabled, these types aren’t in the well-known endpoint, and clients can’t request authorization details.

[ AUT-9557 ] Clients can now subscribe to authorization details types. This feature is currently behind a feature flag.

[ AUT-9558 ] Clients can now use dynamic client registration and provide authorization_details_types as per the RFC9396

[ AUT-9573 ] When a workspace contains multiple IDPs, the UI now directly redirects to the IDP, bypassing the IDP selection page within the workspace. This improves the user experience by automatically handling the selection process.

[ AUT-9575 ] The message has been refined for instances when an invalid JSON is provided in the patch configuration, enhancing clarity and user feedback.

Before:

{"status_code":400,"error":"failed to apply patch: internal server error","details":null}

After:

{"status_code":400,"error":"failed to apply patch: Invalid JSON Patch","details":null}

[ AUT-9591 ] Extended the Open Finance Brazil Consent Management APIs to support requests including v3 payments:

• POST /servers/{wid}/open-banking-brasil/consents
• DELETE /servers/{wid}/open-banking-brasil/consents
• POST /servers/{wid}/open-banking-brasil/consents/{consentID}/consume
• DELETE /servers/{wid}/open-banking-brasil/consents/{consentID}
• GET /servers/{wid}/open-banking-brasil/consents/{consentID}

When a v3 payment consent is targeted with the delete APIs, it receives a rejection reason JSON:

{
 "rejectionReason": {
  "code": "REJEITADO_USUARIO",
  "details": "O usurio rejeitou a autorizao do consentimento"
 }
}

[ AUT-9611 ] Users can now set policies for user, machine, DCR, and developer per authorization details. This feature is currently behind a feature flag.

[ AUT-9668 ] It’s now possible to request authorization_details (RAR) without specifying scopes in the authorization code flow. Previously, if authorization_details was sent with an empty or omitted scope parameter, the default scopes openid email profile were assigned.

[ AUT-9710 ] When attempting a passkey login for a nonexisting user or user without WebAuthn credentials setup, returning a fake credential ID instead of null to obfuscate user existence.

[ AUT-9727 ] Organization templates management and possible to create organization from template

[ AUT-9747 ] A License has been added to the Tenant model:

LicenseType: Indicates the type of license (e.g., trial). Example: trial

StartDate: Specifies when the license begins. Example: 2023-03-01T09:02:27.127932Z

ExpirationDate: Denotes the license’s expiration date. Example: 2023-03-01T09:02:27.127932Z

Developers can reference this model in the API documentation for details on managing and viewing license details associated with a tenant.

It is returned by all tenant API’s but can be modified only by root API.

For new tenants trial license with one year expiration date is assigned. There is no enforcement if license expired. There is no license assignment for existing tenants.

[ AUT-9759 ] When accessing the well-known endpoint via the mTLS domain, the response will now return issuer = mtls_issuer. This adjustment is non-breaking and applies only to new authorization servers or those explicitly migrated to version 3.

[ AUT-9766 ] Added support for the stable 2.1 release of the Open Finance Brazil Consents API.

Bug Fixes

[ AUT-6376 ] Upon deleting an Identity Pool, all associated IDPs will also be removed.

[ AUT-9665 ] Resolved the handling of cert paths for Kong Authorizer. Introduced support for generated_key_type and cert_passphrase in the kong-authorizer charts.

[ AUT-9761 ] For policies NIST-AAL-1,2,3, the allowed amr has been expanded from just “pwd” to also include “otp” and “pop”. This enables authentication via verification code or passkey, which was previously blocked. This update affects all new tenants but remains unchanged for existing tenants.

Recommended Database Versions