9.4 Release Notes

Highlights

  • New 3rd Party API: 
    • User & Attribute management
    • Consent & OAuth controlled
  • Beta: New Workflow Design UI
  • Beta: New Workflow Configuration management
  • Transaction Signing for TB4Mobile
  • Auditing Events: IDHub will now generate events that can be used for auditing. These events are dispatched to a selectable workflow, which can process and store these events.
    • Authentication Events
    • Authorization Events
    • Log-out Events
    • Session Update Events
  • Trustbuilder products can now be deployed using Docker (with Kubernetes or Openshift as container managers)

Changes

  • OAuth, OpenIDConnect:
    • Added support for Refresh tokens in the Token exchange grant (OpenIDConnect)
    • Added support to decrypt the id_token received from oidc service
    • Added support for the "JWT Authentication Type"
    • Made changes that Oauth token values and client secrets are no longer stored
    • Made a change that removes the claims attribute from the URL when using request object
    • "amr" values are now added as multi value attributes to the tokens, instead of overwriting them.
    • Reduced the number of claims shown on a well-known endpoint to those that apply to the SP.
  • TB 4 Mobile
    • Added support to change the Issuer for Mobile IDP's
    • After registering a new TB4Mobile token, the user will now be redirected 
    • Added support to revoke a TB4Mobile registration
  • Added support for auto-provisioning and auto-linking a principal
  • Added Custom Attributes to all Service Provider types
  • Backchannel calls will now set up a TLS channel if a certificate is present
  • The Provisioning workflow now uses the same response format as the Derived Attributes workflow
  • Made a change in the orchestrator behavior. It will now no longer needlessly redirect to gw-login if the session already has the appropriate authentication level.
  • Made a change that GET parameters are now also passed to the internal IDP workflow
  • Added support for wildcards and path parameters in application rules (see below).
  • Several design changes have been made (admin portal, login page, ...)
  • Removed the "return key/value" field from the rules engine
  • Moved the user auditing information (such as "last authenticated") to a separate table so it doesn't trigger a cache update.
  • The application center now shows the user's identity and gives to option to log out.
  • IDHub now accepts and passes the username (or username hint) received from WS Fed SP's
  • The Hikari connection pool will now shut down properly in the event of an undeploy on tomcat.
  • The timeout of a JWKS backend call For an OAuth IDP was increased from 250ms to 2000ms
  • Updated the End-User License Agreement

Bugfixes

  • Fixed a possible exploit in the self-service portal (TB-5523)
  • Fixed an issue where attribute filtering doesn't take categories into account when attributes have the same name (TB-5513)
  • Fixed an issue where PKCE fails if the client_secret parameter is missing (TB-4555)
  • Fixed an issue where deadlocks could occur on the OAuth_Token table, provided REDIS is not used to store tokens. (TB-5441)
  • Fixed an issue where the Hikari Connection pool was sometimes not properly closed (TB-5435)
  • Fixed an issue where the Upload SAML Metadata would fail (TB-5423)
  • Fixed an issue calculating the at_hash value in case of "code id_token token" (TB-5344)
  • Fixed an issue wherethe mobile auth issuer could not be edited (TB-5323)
  • Fixed an issue where the OpenIDConnect userinfo endpoint returns an array for single value attributes. (TB-4928)
  • Fixed an issue that Digipass kernel errors were logged, even if no use of Digipass was enabled. (TB-5277)
  • Fixed an issue where the SLO Signing check did not take the checks from the request parameters into account (TB-5296)
  • Fixed an issue that prevented the same user attributes being used more than once in SP attribute mapping (TB-5452)
  • Fixed an issue that allowed negative values for caching and thresholding (TB-5368)
  • Fixed an issue that prevented OAuth client SP's to be deleted (TB-5557)
  • Fixed an issue that filtered certain characters (XSS) when adding certificates (TB-5583)
  • Fixed an issue with the registration e-mails and password reset e-mails. (TB-5489 and TB-5591)
  • Fixed an issue that showed the IDP client secret in the Self-service IDP (TB-5670)
  • Fixed an issue that didn't properly sort users in IDHub (TB-5619)
  • Fixed an issue where the category wasn't taken into account when filtering users by attribute values, in the case where multiple attributes of the same name were used.  (TB-5513)
  • Fixed an issue where {TB_ID} ws empty when the workflow is called from the orchestrator (TB-5622) 
  • Fixed an issue where removing a user attribute would not check whether that attribute was in use by a policy rule (TB-4753)
  • Fixed an issue with the geoip service (TB-5443)
  • Fixed an issue in the Digipass API that prevented the blocking and re-instating of tokens when there were multiple instances of this token.
  • Fixed an issue that resulted in an internal error when no cookies are in the OIDC password grant_type request  (TB-5669)
  • Fixed a caching update problem for Authentication Schemes and Methods in a clustered environment (TB-5723)

Support for wildcards and path parameters in application rules

TrustBuilder application rules now support URI definitions containing wildcards and path parameters. This new feature is not enabled by default, because in certain scenarios the rules lookup may behave differently than before.

Overview

The TrustBuilder rule engine uses a special lookup structure to locate the application rule that best matches a URI. Given a URI as input (and a HTTP method), the rule engine returns the application rule  with URI that shares the longest prefix with given input URI for that method.

Until now this longest prefix algorithm was textually based, i.e. it treated a URI literally as a string of characters, without any special meaning. With disabled support for wildcards and path parameters, the lookup process of application rules still behaves this way. For instance, given application rules with respective URIs /ab, /abc, /abc/d, /abc/de, all these application rules accept input URI /abc/def. Of these candidates, the application rule with URI /abc/de will be used, since it shares the longest prefix with the input URI.

With enabled support, however, the lookup process behaves somewhat differently.

Given input URI /abc/def/ghi/jkl and application rules with respective URIs /ab, /abc, /abc/d, /abc/de and /abc/def, only /abc and /abc/def match the input. Of these, the rule with URI /abc/def will be used, since this URI shares the longest prefix list of path segments (abc and def) with the input URI. If we still want the input to match, say, /abc/d, we must use an explicit wildcard: /abc/d*. This URI accepts e.g. /abc/d, /abc/de, and /abc/def/ghi.

Enabling and disabling wildcards and path parameters

To enable or disable support for wildcards and path parameters in application rules, go to the "Other" tab on the global Settings screen and check or uncheck "Enable wildcards and path parameters". A TrustBuilder server restart is required for this change to take effect.

Wildcards

An application rule's URI may contain wildcards, specified by the * character. Multiple wildcards may be used in a URI, but only one wildcard is allowed per path segment. In other words, wildcards can be only used to match individual path segments, and a single wildcard does not match a chain of multiple path segments.

Acceptable usages are:

  • a single wildcard, with matches any path segment
  • one or more non-wildcard characters ending in a single wildcard (prefixed wildcards).

Examples

  • input /abc/def/ghi matches /abc/*/ghi
  • input /abc/def/ghi matches /abc/d*/ghi
  • input /abc/def/ghi does not match /abc/e*/ghi

Combined with longest path prefix matching, we also have:

  • input /abc/def/ghi/jkl matches /abc/*/ghi
  • input /abc/def/ghi/jkl matches /*/d*/ghi
  • input /abc/def/ghi/jkl does not match /abc/e*/ghi

Notes

Wildcards may be used with support disabled, but in that case they are interpreted as a regular character without any special meaning.

Currently the gateway passes the complete URL, including the query string, to the authorization service. With disabled wildcard support, an incoming URL like .../abc/def?x=1&y=2 matches application rule URI /abc/def. With wildcard support enabled however, the application rule URI should be changed to /abc/def*.

The current version of the gateway passes the complete URL to the authorization service. Future versions may drop the query string from the input URL. (Query parameters are available in the rule statements.)

Path parameters

An application rule's URI may contain path parameters. Path parameters match segments like single wildcards do, but in addition, they define a path variable name for the resolved path segment. This path variable can then be used in the application rule's statements.

The path parameter is enclosed between a starting { and ending } and must be a complete segment in the rule's URI. The text between the braces is the name of the path variable and must match the regular expression [a-zA-Z][a-zA-Z0-9\-]. In other words, the name should start with a lower or uppercase letter, followed by a combination of zero or more letters, digits or hyphens.

Note that the path segment containing a path parameter must start with { and end in }. If not, that segment is interpreted as a string of characters without any additional meaning.

Path parameters cannot be used in rule statements when support is disabled.

When used in rule statements, path parameters accept the same operations as headers, cookies and query parameters.

Examples

  • input /abc/def/ghi matches /abc/{var1}/ghi
  • input /abc/def/ghi matches /abc/{PATH-VAR}/ghi
  • input /abc/def/ghi does not match /abc/d{not-a-path-var}/ghi

Combined with longest path prefix matching, we also have:

  • input /abc/def/ghi/jkl matches /abc/{var1}/ghi
  • input /abc/def/ghi/jkl matches /abc/{PATH-VAR-1}/{PATH-VAR-2}
  • input /abc/def/ghi/jkl does not match /abc/d{not-a-path-var}/ghi

Note

Internally, the rule engine does not distinguish between names of path parameters appearing in the same position. A future version of TrustBuilder may enhance the validation process to locate these path parameter aliases.

For instance, given an application rule with URI /abc/{var-1} and another rule with URI /abc/{var-2}, input  /abc/def matches both rules. Which one is returned from the lookup process is undefined.

Deprecation Notice

  • Due to a licensing change by Oracle, they no longer offer support for Version 8 JDK. We've moved to OpenJDK as the default.

9.4.1 Release Notes

  • Fixed an Internal Server issue when using a WS Fed. Service Provider (TB-5863)
  • Fixed an issue with Attribute mapping when "lookup principal" is set to false (TB-5844)
  • Fixed an issue where the client secret is queried, even when using JWT client authentication. (TB-5779)
  • Fixed an issue in OIDC when exchanging a Refresh token for an Access token (TB-5802)
  • Requesting an OIDC Token via the Token Exchange Grant, now also returns a refresh token (TB-5795)
  • Added the Arbitrator role to the appliance package (TB-5859)
  • Workflow Designer TBWD home directory is now set at installation (TB-5857)
  • Fixed an issue where the new Workflow Designer could not be started after a clean install (TB-5791)
  • Fixed an issue in the validation of the SAML logout response, ID's are now always proceeded by "IDHUB_" (TB-5777)
  • The X-TB-AZN-CACHE header is no longer passed unnecessarily to the browser (TB-5692)
  • Fixed an "Upstream prematurely closed" issue in the Gateway while reading the response header from upstream by adding a retry. (TB-5693)
  • Fixed an issue in Redisson that resulted in a NullPointer when no relaystate was provided (TB-5896)
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.