January 31, 2024

Highlights

Unlock the Future with Beta Features UI

Tenant Administrators are now in the driver’s seat! Gain full control over your Cloudentity experience by enabling or disabling beta feature flags for your tenant. Explore the latest innovations and shape the future of identity and access management with ease

Tailored Consent Experience - Your Claims, Your Choice

We’ve integrated requested claims into OAuth/OIDC consent pages. Now, users have the power to choose which claims they share with Relaying Parties. Want to try it out? It’s in beta, and administrators can enable or disable this capability with the identity_assurance feature flag.

Enhanced Token Exchange and Authorizers

We’ve fine-tuned support for Kong 3.x, addressing compatibility challenges that arise during the transition from 2.x to 3.x, particularly when dealing with routes defined using regular expressions. Additionally, we’ve introduced advanced configuration options for Istio and Kong authorizers, allowing you to finely control which scopes are requested for new tokens as part of the authorizer-initiated token exchange flow. Plus, we’ve improved error handling in the authorizer-initiated token exchange process.

Breaking changes

[ AUT-10686 ] For the new tenants, the tenant owner will be directed to the new “Get Started” experience instead of the existing Workspaces selection.

Major additions and changes

[ AUT-10635 ] Beta features UI. Tenants Owners now have the capability to enable/disable beta feature flags for their tenant.

[ AUT-10561 ] Introducing Advanced Scope flag - “Implicit Grant”. When enabled, users are no longer prompted for consent when requesting the target scope because it’s automatically granted. In simpler terms, if you request scopes under the implicit grant category, you won’t see them on the consent page with other scopes. In fact, if every requested scope falls under implicit grant, you won’t even encounter the consent page

Identity Assurance and Verified Claims

Feature still in beta, administrators can enable or disable this capability with the identity_assurance feature flag.

[ AUT-10127 ] Requested claims are now integrated into OAuth/OIDC consent pages, enabling users to select which claims are shared with the Relaying Parties.

[ AUT-10261 ] GET /clients clients listClientsWithAccess API now returns granted claims per Client for a requested subject.

[ AUT-10585 ] Verified Claims support in the admin portal

Open Finance Brazil improvements

[ AUT-10765 ] Added an introspection endpoint for the payment consent, as required by the Open Banking payments specification updates (v4).

[ AUT-10785 ] Added support for RSA-OAEP as an encryption algorithm and well-known endpoint fixes

Before this change request_object_encryption_alg_values_supported property in the well-known page had a fixed value:

"request_object_encryption_alg_values_supported": [
 "RSA-OAEP",
 "RSA-OAEP-256"
],

After this change request_object_encryption_alg_values_supported is rendered based on actual server jwks encryption keys. By default, only one encryption key is generated with RSA-OAEP-256 algorithm, the updated well-know entry for request object encryption now includes :

"request_object_encryption_alg_values_supported": [
"RSA-OAEP-256"
],

Additionally, by default any new Open Banking Brazil workspaces will use RSA-OAEP request object encryption as per spec, so the corresponding well-known entry will be following:

"request_object_encryption_alg_values_supported": [
  "RSA-OAEP"
],

Minor enhancements

[ AUT-10722 ] Returning users land on recently used workspace.

[ AUT-10747 ] Under OAuth/OIDC settings the Tokens' & Claims' configuration is now split into two separate side navigation items

[ AUT-10778 ] Token Exchange Improvements: Before this modification, the token exchange took place within the authorizer, relying on the configuration within Gateway Management -> 3rd party tokens -> Enable exchange of third party tokens to Cloudentity access tokens.

In cases where the token exchange wasn’t activated in the authorizer configuration:

  token_exchange:
    enabled: false

it resulted in an exchange error during the invocation of the system exchange token API, due to the absence gateway_exchange_tokens scope.

After this change, the token exchange only occurs when both flags are concurrently enabled.

[ AUT-10806 ] Kong 3.x support enhancement. Kong introduced a breaking change when switching from 2.x to 3.x in case where routes are defined using regexp, more details: https://docs.konghq.com/kubernetes-ingress-controller/2.6.x/guides/upgrade-kong-3x/#update-ingress-regular-expression-paths-for-kong-3x-compatibility

Before, when the ingress controller had paths defined using regexp (for example: /~/(?i)status), and kong authorizer was running with discovery enabled, it discovered it as ~/(?i)/status and with the Kong v3 calling this endpoint could would cause NO_RULE error.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example
  annotations:
    konghq.com/strip-path: 'true'
    konghq.com/plugins: 'my-acp-plugin'
spec:
  ingressClassName: kong
  rules:
  - http:
      paths:
      - path: /~/(?i)status
        pathType: ImplementationSpecific
        backend:
          service:
            name: example
            port:
              number: 1027

This change addresses that problem. If the authorizer discovers that Kong 3.x is used, and the path starts with the regex for instance: /~/(?i)status, it will drop ~ and API will be correctly discovered as /(?i)status.

[ AUT-10815 ] Istio and Kong authorizers can now configure what scopes should be requested for a new token when performing authorizer initiated token exchange.

Configuration:

token_exchange:
  request_scopes: "original_token" # one of: "original_token", "client"

The original_token represents the existing behavior, where requested scopes are derived from the original token. With the new client option enabled, the authorizer requests scopes assigned to a token exchange client, instead of deriving the scopes from the original token.

Bug fixes

[ AUT-10488 ] Bug fix in the self-set password flow using the new User Self-Service Portal, which was preventing some users from setting the password.

[ AUT-10572 ] Hide the password setting option in the user create modal if the password is not one of the available authentication methods in the identity pool.

[ AUT-10739 ] When there are no IDPs in the workspace that can handle resource owner password grant flow authentication, change the status code from 500 to 401.

[ AUT-10796 ] Authentication provider caching bug fix in the identity orchestration that was preventing authentication via the recently created identity provider.