| Table of Contents |
|---|
4.1.0 (April 11, 2024)
This is a feature release accompanying a new version of the OIDC commons library along with some general improvements and minor bug fixes. It is compatible with Shibboleth IdP 5.0 or later.
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
OIDC Logout
The OP plugin now includes the new OPLogout profile. The new OIDC.Logout profile implements the RP-initiated logout and logout propagation via both front- and back-channel. The profile documentation has a section for slight modifications needed for two logout templates if non-default versions prior to IdP 5.1 are used.
Acknowledgement to DAASI: their OIDC back-channel logout propagation plugin was used as a basis for this implementation.
Refresh token extensions
We have refactored the refresh token encoding and decoding code and it’s now fully customisable. This advanced feature is provided via two new properties idp.oauth2.refreshToken.serializationStrategies and idp.oauth2.refreshToken.deserializers: those can be used for injecting any custom beans to encode and decode refresh token values, and thus provide support for for new refresh token types. We demonstrate this new functionality by supporting a new JWT refresh token type.
Policies for dynamic registration and unregistered clients
The https://shibboleth.atlassian.net/wiki/x/AoC_rw used in dynamic client registration and for unregistered clients can now be extended with custom operators. A new metadata policy operator bean provides flexible means for validating incoming requests via a fully customisable set of beans. See https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/2948497410/OPMetadataPolicies#Custom-operators-4.1 for details.
Metadata-driven claim naming
The RP-specific claim names can now be configured in the metadata-driven fashion. See https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879159/OPAttributeResolution#SAML-metadata-driven-claim-name for more details.
Identifier configuration
The identifier generation configuration has been harmonised: a new configuration property (idp.oidc.xmlSafeIdentifiers) can be used to control whether to generate XML ID safe identifiers, which was previously always the case. If the property is set to false (default is true), the identifiers (such as JWT token IDs) won’t contain the _-prefix anymore and the OP can, for instance, create UUIDv4 compatible identifiers if desired.
Message logging improvements
The request and response messages containing JSON structures are now pretty-printed on TRACE level. Also the JWT token payloads produced by the OP plugin are pretty-printed to the protocol message logs on that level.
New configuration properties
idp.oauth2.refreshToken.type: a format of refresh token. Supported values are “JWT” or nothing/empty/null, implying opaque tokens.
idp.oauth2.refreshToken.serializationStrategies: a custom bean reference containing the map of refresh token serialisation strategies, key refers to the refresh token type.
idp.oauth2.refreshToken.deserializers: a custom bean reference containing the list of refresh token deserialisers.
idp.oauth2.responseModes: a comma-separated list of allowed response modes. Empty by default which refers to no restrictions.
idp.oidc.xmlSafeIdentifiers: a flag to signal if XML ID safe identifiers should be used when generating identifiers.
idp.oidc.logout.encryptionOptional: a flag to automatically disable back-channel logout token encryption if the relying party does not possess a suitable key.
idp.oidc.logout.preferFrontChannel: a flag to prefer front-channel logout propagation if both front and back -channel URIs are defined in the RP metadata
idp.oidc.logout.frontChannelSuccess: a flag to consider front-channel logout propagation success in the propagation UI (defaults to false).
idp.oidc.logout.revokeTokens: a flag to revoke the access and refresh tokens related to the session (defaults to true). Note that the OAUTH2.Revocation profile must be enabled for the RP.
idp.oidc.logout.requireIdTokenHint: a flag to require the use of id_token_hint parameter in the RP-initiated logout request.
idp.oidc.logout.logoutHintMatchingStrategy: a custom bean reference to bi-predicate for matching the logout_hint parameter with an SPSession.
New configuration beans
shibboleth.oidc.RevokeConsentPredicate: A predicate to signal if prior consent should be revoked.
shibboleth.oidc.UnregisteredClientPolicyValidator: A validator bean used for validating the configured policy for unregistered clients.
shibboleth.oidc.UnregisteredClientPolicyEnforcer: An enforcer bean used for enforcing policy for unregistered clients.
shibboleth.oidc.dynreg.ClientIDGenerationStrategy: An identifier generation strategy used for generating client IDs in dynamic client registration.
shibboleth.oidc.dynreg.ClientSecretGenerationStrategy: An identifier generation strategy used for generating client secrets in dynamic client registration.
shibboleth.oidc.dynreg.MetadataPolicyValidator: A validator bean used for validating the configured metadata policy in dynamic client registration.
shibboleth.oidc.dynreg.MetadataPolicyEnforcer: An enforcer bean used for enforcing metadata policy in dynamic client registration.
4.0.0 (September 14, 2023)
This is a feature release accompanying a new version of the OIDC commons library along with some general improvements and minor bug fixes. It is the first release that requires Shibboleth IdP 5.0.0 or later. Previous versions of the plugin are not compatible with IdP 5.
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Policies for unregistered clients
In addition to the request validation against client metadata (JSON or SAML), the plugin now supports validation against a policy for unregistered clients. A policy is used for validating the incoming client ID, scope, redirection URI, and response type parameters or their subsets, depending on the endpoint where the validation is done. If the request is compliant with the policy, the unverified profile configuration is applied. The validation against policy is only performed with the unverified profile configurations (see shibboleth.UnverifiedRelyingParty in RelyingPartyConfiguration ). The verified profile configurations (shibboleth.DefaultRelyingParty and shibboleth.RelyingPartyOverrides) still require the registered client metadata in the same way as before.
Elimination of the custom response header filter
The previously existing method for configuring custom HTTP headers for the plugin’s endpoint has now been removed. Now the plugin automatically extends the IdP’s known set of URL prefixes to apply its response headers to by adding the /profile/oidc/ and /profile/oauth2/ prefixes to the built-in set.
See OPCustomFilterRegistration .
New configuration properties
idp.oidc.DefaultUnregisteredPolicyFile - it defaults to %{idp.home}/conf/oidc-unregistered-client-policy.json. An example file is included in the distribution.
Removed configuration properties
idp.oidc.ResponseHeaderFilter: It was related to the now removed custom response header filter
idp.oidc.refreshToken.defaultLifetime: already deprecated in version 3.3.0, use idp.oidc.refreshToken.defaultTimeout instead
New configuration beans
shibboleth.oidc.Conditions.MetadataValueEquals: a utility bean to be used for instance with activation conditions to match if a specific metadata claim contains a specific value
shibboleth.oidc.PlainRequestObjectClaimsValidation: If defined, it will be used for the validation of unsigned request objects
shibboleth.oidc.SignedRequestObjectClaimsValidation: If defined, it will be used for the validation of signed request objects
3.4.0 (May 15, 2023)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This is a feature release accompanying new version of the OIDC commons library along with some general improvements and minor bug fixes. It is the first release designed to co-exist with the new OIDC RP authentication plugin.
This release addresses security advisory (https://shibboleth.net/community/advisories/secadv_20230512.txt) related to a pair of race conditions in the client authentication and dynamic registration features.
This release requires Shibboleth IdP 4.3.0 or later and the OIDCConfig plugin. Please note that the version 1.0.1 was released on May 16, 2023 to fix issues (see first and second) related to default OIDC.SSO and OAUTH2.Token configurations.
Security Configuration
The old security configuration mechanism has been replaced with the new security configuration style, designed to be compatible with the new OIDC RP authentication plugin. Any custom security configuration dating to previous versions will require modifications, but this is expected to have been rare.
The underlying Java class for the shibboleth.oidc.DefaultSecurityConfiguration parent bean has changed, and thus any custom beans extending that need to be adapted. The previous class is no longer compatible with the plugin.
The new class bean has the following properties:
jwtSignatureSigningConfiguration (related property idp.oidc.signing.config, NOTE, any previously configured bean needs to be adapted)
jwtEncryptionConfiguration (related property idp.oidc.encryption.config, NOTE, any previously configured bean needs to be adapted)
jwtDecryptionConfiguration (related new property idp.oidc.decryption.config)
jwtSignatureValidationConfiguration (related new property idp.oidc.validation.config)
The following configuration parameters (and related properties) are no longer supported:
requestObjectDecryptionConfiguration (property idp.oidc.rodecrypt.config is ignored)
use jwtDecryptionConfiguration with OPAuthorization
requestObjectSignatureValidationConfiguration (property idp.oidc.rovalid.config is ignored)
use jwtSignatureValidationConfiguration with OPAuthorization
tokenEndpointJwtSignatureValidationConfiguration (property idp.oidc.tevalid.config is ignored)
use jwtSignatureValidationConfiguration with OPToken , OPRevocation and OPIntrospection
New Supported Algorithms
The set of supported algorithms has been extended to include:
PS256, PS384 and PS512 signature algorithms
RSA-OAEP-384 and RSA-OAEP-512 encryption algorithms
ECDH-ES+A128KW, ECDH-ES+A192KW and ECDH-ES+A256KW encryption algorithms
Refresh Tokens
The OPToken profile now contains new profile configuration options to control the expiration of both single and chains of refresh tokens. We also deprecated the previously existing option and property related to the expiration of a single token.
NOTE: The default lifetime for the chain (refreshTokenChainLifetime -option and idp.oidc.refreshToken.defaultChainLifetime -property) is 2 hours. This new option may need to be adjusted to keep any longer-lived refresh tokens valid.
Refresh tokens can now be issued for OAuth2 (non-OIDC) clients via the authorization code grant, if the necessary profile configuration option is set. The OIDC clients still need to use offline_access scope, as before.
A new profile configuration option (issueIdTokenViaRefreshToken) now exists for controlling ID token issuance when the refresh token grant is used and defaults to true.
Request Objects
The OPAuthorization profile now contains new profile configuration options to control the use of request objects.
JWT-based Client Authentication Improvement
The audience validation for JWTs used in client authentication has been modified. The token, introspection and revocation endpoints now accept the OP issuer value, the requested endpoint URL and the token endpoint URL values as an audience. In the older versions, only the requested endpoint URL was accepted.
The validation key handling has also been improved: if the header of an incoming JWT contains a key reference (the kid claim), it must now match to a trusted key.
3.3.0 (November 29, 2022)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This is a feature release that adds support for OAuth2 (non-OIDC) authorization requests along with some general improvements and minor bug fixes.
The OIDC.SSO profile can now be configured to also accept plain OAuth2 authorization requests. Before this release, the RPs were required to use OIDC authentication requests. It remains the default behaviour, but it can be configured via idp.oauth2.requireAuthenticationRequestPredicate property.
3.2.1 (July 7, 2022)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
OIDC/OAuth request and response messages are now logged via the PROTOCOL_MESSAGESMESSAGE.OAUTH2 category (a sub-category of the one used for SAML, which we will likely migrate to a subcategory in a future IdP release). At DEBUG level, it logs the contents of the Java message objects, without revealing the value of client secrets or HTTP Basic-Auth headers. At TRACE level, it logs the messages in raw form, including both HTTP headers and message body contents. The TRACE level matches the logging that was previously done by the decoder/encoder class loggers on DEBUG level.
...
This is a patch release, primarily addressing
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
This is a patch release, primarily addressing
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...