Release Notes: SecureAuth 2.21.0

Tenant Administrators are now in the driver’s seat! Gain full control over your SecureAuth 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

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.

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.

For the new tenants, the tenant owner will be directed to the new "Get Started" experience instead of the existing Workspaces selection.

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

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

Returning users land on recently used workspace.

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

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 SecureAuth 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.

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.

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 fix in the self-set password flow using the new User Self-Service Portal, which was preventing some users from setting the password.

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.

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.

Authentication provider caching bug fix in the identity orchestration that was preventing authentication via the recently created identity provider.