The built-in Velocity template for the user consent screen (views/oauth/consent.vm) was updated so that the displayed claim values are HTML-encoded. Any custom templates should be updated accordingly by using the $_tr.encodeHtml function.
views/oauth/consent.vm
$_tr.encodeHtml
An @Experimental service class se.curity.identityserver.sdk.service.issuer.NonceIssuer was updated and is no longer generic. Custom nonce and authorization code issuers can be configured using this service.
@Experimental
se.curity.identityserver.sdk.service.issuer.NonceIssuer
nonce
authorization code
The configuration model of the experimental feature Token Procedure Plugins has changed in a non backward compatible way. In versions 8.0 and 8.1, token procedure plugins were configured in the /processing/procedures/token-procedure-plugin list. In version 8.2 the configuration moved into an OAuth profile, specifically into the /profiles/profile/settings/authorization-server/token-procedure-plugins list. This also means that token procedure plugins are now configured under a different XML namespace. The following example will show what needs to be done to migrate existing token procedure plugins.
Token Procedure Plugins
/processing/procedures/token-procedure-plugin
/profiles/profile/settings/authorization-server/token-procedure-plugins
<config xmlns="http://tail-f.com/ns/config/1.0"> <processing xmlns="https://curity.se/ns/conf/base"> <procedures> <token-procedure-plugin> <id>custom-token-procedure-plugin</id> <custom-token-procedure-plugin xmlns="https://curity.se/ns/ext-conf/custom-token-procedure-plugin"> <my-boolean-value>true</my-boolean-value> </custom-token-procedure-plugin> </token-procedure-plugin> </procedures> </processing> </config>
A new token procedure plugin configuration would look like this:
token procedure plugin
<profiles xmlns="https://curity.se/ns/conf/base"> <profile> <id>oauth-dev</id> <type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type> <settings> <authorization-server xmlns="https://curity.se/ns/conf/profile/oauth"> <token-procedure-plugins> <token-procedure-plugin> <id>custom-token-procedure-plugin</id> <custom-token-procedure-plugin xmlns="https://curity.se/ns/ext-conf/custom-token-procedure-plugin"> <my-boolean-value>true</my-boolean-value> </custom-token-procedure-plugin> </token-procedure-plugin> </token-procedure-plugins> </authorization-server> </settings> </profile> </profiles>
Notes:
The following example shows how the usage of a token procedure plugin on an OAuth endpoint needs to updated:
<profiles xmlns="https://curity.se/ns/conf/base"> <profile> <id>oauth-dev</id> <type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type> <endpoints> <endpoint> <id>token-dev</id> <uri>/dev/oauth/token</uri> <endpoint-kind>oauth-token</endpoint-kind> <token-endpoint-procedures> <flow>oauth-token-client-credentials</flow> <token-procedure-plugin>custom-token-procedure-plugin</token-procedure-plugin> </token-endpoint-procedures> </endpoint> </endpoints> </profile> </profiles>
<profiles xmlns="https://curity.se/ns/conf/base"> <profile> <id>oauth-dev</id> <type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type> <endpoints> <endpoint> <id>token-dev</id> <uri>/dev/oauth/token</uri> <endpoint-kind>oauth-token</endpoint-kind> <token-endpoint-procedures> <flow>oauth-token-client-credentials</flow> <token-procedure-plugin xmlns="https://curity.se/ns/conf/profile/oauth"> custom-token-procedure-plugin </token-procedure-plugin> </token-endpoint-procedures> </endpoint> </endpoints> </profile> </profiles>
There’s just one slight difference - token procedure plugins need to be configured in a different XML namespace. See the emphasized line in the above listing.
The claims system was updated with the support for reference- and composite-claims. Part of this change involves updating the configuration model. This results in enforcing the requirement that every claim must be configured with a means to resolve to a value. This requirement now rejects claims without a claims provider (i.e. static claims) that do not have a generator procedure configured.
Before 8.2, it was possible to configure such a claim, which was wrong as it was impossible for the claim to resolve to a value. So since 8.2, it is enforced in a way that a static claim must now be configured with a procedure.
When upgrading, ensure that there are no static claims configured without a generator procedure. If your configuration does contain such claims, create a procedure for it that returns a value, before upgrading to 8.2.
See Value transformation or generator procedure for more information on claim transformation procedures.