Connect2id server 15.2

This Connect2id server release ships an update to the plugin interface (SPI) for sourcing claims (also called attributes) that get provided to client applications at the UserInfo endpoint and may also be fed into ID tokens and access tokens. The change enables plugins to find out the browser session ID where the claims sourcing was authorised.

The included plugin that delegates the claims sourcing to an HTTP endpoint was updated accordingly, so that web hooks that source such claims for the Connect2id server can find out the session ID or receive the complete session object. Note that the HTTP claims source plugin must be explicitly configured to receive these details, they will not be included by default.

This release also adds a measure to prevent the dispatch of back-channel logout notifications when the issuer alias mode PERSISTED_GRANT_ISOLATION is configured.

More information is available in the release notes below.

The dockerfile for the c2id/c2id-server-min image received a significant update that can be considered breaking. The c2id.war is now being copied unzipped to the docker image, to make it easier to edit its configurations files, for example the WEB-INF/log4j.xml that controls logging.

Download 15.2

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 15.2: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: 0d7b3bb9d560b6d6c0028fb11274912c1d9bb1f1afc066e2fca8f6d9fdb44b63

Connect2id server 15.2 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: 7888bcc9fc60baea6051b780a1902d3c24fcfdc505431e954ade47b014a3e96b

Multi-tenant edition

Apache Tomcat package with Connect2id server 15.2: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: a09525dddc227d600555046b510a5d5007198a646e9b8af99a8ffd65c3b9e91f

Connect2id server 15.2 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 3e4304f5767264aaccf856423a742579871ba04218b0e2c065b69af60bfa1aa0

Questions?

For technical questions about this new release contact Connect2id support. To purchase a production license for the Connect2id server, renew or upgrade your support and updates subscription, email our sales.


Release notes

15.2 (2024-02-16)

Configuration

  • /WEB-INF/httpClaimsSource.properties

    • op.httpClaimsSource.includeSubjectSessionID -- New optional configuration property of type boolean. Enables / disables inclusion in the request of the subject (end-user) session ID where the claims sourcing was authorised. Disabled by default.

    • op.httpClaimsSource.includeSubjectSession -- New optional configuration property of type boolean. Enables / disables inclusion in the request of the subject (end-user) session where the claims sourcing was authorised. Disabled by default.

SPI

  • Upgrades the Connect2id server SDK to com.nimbusds:c2id-server-sdk:5.2

    • New ClaimsSourceRequestContext.getSubjectSessionID method that returns the ID of the associated subject (end-user) session where the claims sourcing was authorised.

    • New SubjectSessionID interface to represent subject (end-user) session identifiers.

Resolved issues

  • When the op.issuerAliasMode configuration property is set to PERSISTED_GRANT_ISOLATION back-channel logout notifications on subject session close and expiration events must be disabled (issue server/969).

Dependency changes

  • Upgrades to com.nimbusds:c2id-server-sdk:5.2

  • Upgrades to com.nimbusds:oidc-claims-source-http:3.0

  • Updates to Log4j 2.22.1

Connect2id server 15.1.1, 14.11.1

If you have a Connect2id server deployment with client applications registered to receive front-channel or back-channel logout notifications we strongly recommend that you apply this update. It fixes a thread-safety bug that under certain timing conditions could cause clients to receive a bad or duplicate sid (session ID) claim in the ID token. This then breaks the logical link between the ID token and a logout notification that the client may receive in future.

Updates are provided for both Connect2id server 15.x and 14.x.

If you have a CVE tool it may have recently reported a CVE-2023-51074 and a CVE-2024-21634. Connect2id server deployments are not affected. The libraries that received the CVE reports are used by the server to parse its own configuration properties. They are not used to process user or API input. On the 15.x branch the affected dependencies were updated (along with a few others).

The next Connect2id server releases are going to include new features that have been in the pipeline for some time, such as support for automated cluster-wide key generation and rollover. The upcoming OpenID Federation 1.0 standard is also going to become a more prominent part of the Connect2id server. To find out more about it:

  • Check out the article on the X.509 certificate chain vs the OpenID trust chain talk at the OpenID 2024 Summit in Tokyo, Japan.

  • Meet the specification editors this week at the TIIME event in Copenhagen.

  • Find out how a future TLS 2.0 using OpenID Federation 1.0 trust chains could look like, at the Trends in Digital Identity 2024 in April in Rome, Italy.

  • Another opportunity to meet the editors and implementers is going to be the OAuth Security Workshop, also in April in Rome. Registration will open soon.

  • At Identiverse in May, in Las Vegas.

  • At the European Identity and Cloud Conference 2024 in Berlin, in June.

Download 15.1.1

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 15.1.1: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: e15885b8728fe01bce3702414d42581085216031bdfe5e7b7645d9247da77326

Connect2id server 15.1.1 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: 932b64b89decdede03fa6f053f9c7915fab6d264b0b1399544c529860808c89b

Multi-tenant edition

Apache Tomcat package with Connect2id server 15.1.1: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: 8510ea0b7abd233316258d54ebd09add3a4f5ccd6fa07a2d8066171c781fe3f7

Connect2id server 15.1.1 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 976ddce9725ec6a2f5d49e6b011f7976602b56c94b613b4d3cd8990833707416

Download 14.11.1

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 14.11.1: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: 3ab40362e471ac812298e6ed419d4d0fc6faca4297053972cfe716500f1e5968

Connect2id server 14.11.1 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: fb8dbdfa7e1c00a97fa77d12a1fc73f7f2bab915390377dbe686b1b141a78c3d

Multi-tenant edition

Apache Tomcat package with Connect2id server 14.11.1: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: 717f5718b240db701c0d630d7f9c90ef6359a0a530c6e6c7b907215b70121f4a

Connect2id server 14.11.1 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: d7986a02adaefac48fbe204d3fec1e503ba23c0028a1cecac33e73fe2f2c02f1

Questions?

For technical questions about this new release contact Connect2id support. To purchase a production license for the Connect2id server, renew or upgrade your support and updates subscription, email our sales.


Release notes

15.1.1 (2024-01-29)

Resolved issues

  • Fixes generation of the optional "sid" (session ID) claim in ID tokens which relied on a non-thread safe use of a SHA-256 message digest. In Connect2id server deployments when two or more "sid" claims need to be generated within a short length of time (<< 1 second) this could result in the "sid" claim receiving an incorrectly computed value or cause the value to leak into the "sid" claim of another ID token. Connect2id server deployments with clients / OpenID relying parties registered to receive logout notifications with a "sid" parameter are strongly advised to update (issue server/967).

Dependency changes

  • Updates to com.nimbusds:infinispan-cachestore-dynamodb:6.0.1

  • Updates to com.nimbusds:c2id-server-property-source:2.0.1

  • Updates to com.nimbusds:software-statement-verifier:2.2.7

14.11.1 (2024-01-29)

Resolved issues

  • Fixes generation of the optional "sid" (session ID) claim in ID tokens which relied on a non-thread safe use of a SHA-256 message digest. In Connect2id server deployments when two or more "sid" claims need to be generated within a short length of time (<< 1 second) this could result in the "sid" claim receiving an incorrectly computed value or cause the value to leak into the "sid" claim of another ID token. Connect2id server deployments with clients / OpenID relying parties registered to receive logout notifications with a "sid" parameter are strongly advised to update (issue server/967).

The OpenID trust chain vs the X.509 certificate trust chain

This is a transcript of my talk at the OpenID Summit that took place in Tokyo Japan in January 2024. It was an entertaining 15 minutes that focused on the upcoming OpenID Federation 1.0 and how standards can sometimes have unintended uses and consequences.

Fun fact: According to Wikipedia Godzilla has been the longest running and most viewed movie franchise in Japan!

This talk has two objectives:

  1. To compare, at a high-level, the Trust Chain and the X.509 certificate chain.

    What is the Trust Chain? The Trust Chain is the hero, the central character in the new standard for federating Internet services, applications and devices developed at the OpenID Foundation.

  2. Given the 10 year anniversary of OpenID Connect, we’ll also talk about the magic and unanticipated uses and consequences of computer standards.

The X.509 certificate has achieved a silent "monstrous" presence on the planet. I reach into my pocket where my credit card is - and it has an X.509 certificate stored in its microchip. I reach into my other pocket where my smartphone is - it has dozens of root certificates in the OS, the browser and probably many more certificates in installed applications. There are millions web servers around the world and all that that allow HTTPS have certificates.

Was this success planned or envisioned by the people who invented the X.509 certificate?

1988 - the year of the X.509 certificate

Probably not, because X.509 became a standard in 1988. Several years before the World-Wide Web, the browser and SSL / TLS were invented.

1988 - the year of the X.509 certificate

What helped the success of the X.509 certificate?

It does what it does, in a simple and elegant manner. It binds, cryptographically, a name to a public key.

The certificates can be neatly chained, up to a trusted authority.

The chains are compact too. Owing to the 1980s, when big storage was measured in megabytes and network speed in kilobits per second. This is what made the binary ASN.1 encoding so hot and sexy in those days.

The X.509 internals

Let's double click on the X.509 certificate:

  • It has a name of the issuer and the name of the subject, i.e. the entity that holds the public key.

  • It has a validity time window.

  • Some optional constraints.

  • And of course, a single public key.

That’s how simple the certificate is. If we forget the extensions, which tend to get ignored, and when they aren't being ignored they tend to crash the validation 😁

The Trust Chain JWT internals

Fast forward to the 2010s.

Roland Hedberg from Sweden invented the JWT Trust Chain to enable OpenID Connect relying parties and OpenID Connect providers to magically federate, using authorities called Trust Anchors.

In its minimal form the Trust Chain JWT looks pretty much like a X.509 certificate.

Yes, it differs in the encoding (JWT vs ASN.1), but also in some crucial fields that give its magic and open up new possibilities:

  • It has a dedicated field for metadata. So that, for instance, OpenID relying parties can securely and automatically get registered by OpenID providers.

  • It has a field for metadata policies. So that a trust anchor could for instance set a metadata policy for the FAPI profile.

    OpenID Connect specifies 65 (!) metadata parameters, with more in various extensions. This is a good example of an unintended consequence in a computer standard. Would Roland have invented these capabilities for entity-typed metadata and its policing if the authors of OpenID Connect didn’t create these 65 metadata parameters? Probably not 😁

  • It has a field for including 3rd party accreditations, as JWTs, called trust marks.

The trust vs the x.509 certificate chain comparison table

This table gives us a neat overview of what extra capabilities the JWT trust chain has.

Two features must be noted because they are not obvious from the previous slide which showed the content of a trust chain JWT:

  • The properties of the Trust Chains enable federations to closely reflect the needs and realities of the real world. Federations can be anchored in more than one authority, nested, and / or incorporate additional dimensions of trust in the form of trust marks.

  • In 1988 we did not have web APIs, but today we do. This means a Trust Chain can be discovered and built by starting from an entity’s well-known federation URL. Applications can call federation web APIs to build and validate Trust Chains in real time. Applications can also query trust anchors and intermediate authorities and thus navigate / crawl federations.

1988 - the year of the X.509 certificate

Let's fast forward the timeline to 2035.

This is the year when Elon Musk finally brings humans on Mars 😁

The other big news of the year is the release of TLS 2.0, which replaces the X.509 certificate chain with the OpenID Trust Chain.

1988 - the year of the X.509 certificate

So, it’s 2035 and at the OpenID Foundation board meeting prior to the OpenID Summit in Tokyo the board decides to upgrade the openid.net website to TLS 2.0. Remember, this is the year 2035, so it hasn’t happened yet 😁

We click on the openid.net padlock icon and what do we see?

Wow, we see new things that weren’t present there before!

We see the usual field that says which authority verified the openid.net domain name.

Next to it we see a second field.

In OpenID Federation you can have entities present a single JWT that can lead to more than one trust anchor.

So, the second Trust Chain leads to the Internal Revenue Service (IRS) of the US where the OpenID Federation is registered as a non-profit organisation. In 2034 the IRS decided to become an OpenID trust anchor and so every company and non-profit in the United States can obtain a Trust Chain JWT from the IRS by enrolling its public JWK set.

The other items that you see are trust mark JWTs issued to the OpenID Foundation. That the OpenID Federation has obtained a trust mark from the Bank of America because it holds an account with the bank. And that the organisation has received certain certifications, like for having received Mars survival training. These trust marks are embedded in the Trust Chain.

1988 - the year of the X.509 certificate

So what has the Trust Chain achieved in the year 2035?

It has changed the paradigm of TLS and internet security in general, by evolving the infrastructure, from Public Key Infrastructure (PKI) to a more comprehensive Trust Infrastructure.

That’s pretty big news in 2035!

1988 - the year of the X.509 certificate


The slide deck in PDF:

The Trust Chain vs the X.509 Chain

Connect2id server 15.1

This mini update of the Connect2id server addresses three issues reported last week.

The optional op.reg.rejectNonTLSRedirectionURIs configuration property that enables the HTTPS requirement for redirection URLs in the OAuth 2.0 code flow to be relaxed gets extended to cover native applications as well. Previously it affected web applications only. The relaxing of the HTTPS redirection_uri requirement is intended primarily for testing and development purposes and should not be used in production.

Registration of native (mobile and desktop) applications as OAuth 2.0 clients and OpenID relying parties and what types of redirection URIs are accepted is explained here.

This release also addresses two issues related to the processing of requests at the authorisation endpoint. The parsing of requests was hardened to ignore query parameters with illegal escape sequences so that they won't produce an unchecked exception and an HTTP 500 Server Error in the API. A bug that affected the correct application of configured scope value to claims mappings in prompt=none requests and requests that get cleared entirely from stored consent was also fixed.

A slightly more detailed information can be found the release notes below.

Download 15.1

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 15.1: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: 9057fca2e7b37ef9fb19fdae1fde468f82ba9cc90d03d760de3006b69e53a928

Connect2id server 15.1 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: fc7c74fd689d40080f319fc68d06f64e5d3d7fd9afb80acac024ab45c1936c05

Multi-tenant edition

Apache Tomcat package with Connect2id server 15.1: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: 6e6796cc4609a03cc29d8784746a4518685260dc0637c6c777735125366f60e1

Connect2id server 15.1 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 3f819529e02ac7e4d66796cd5a5801f8bceb712b8511598065c9fd2695bd0c90

Questions?

For technical questions about this new release contact Connect2id support. To purchase a production license for the Connect2id server, renew or upgrade your support and updates subscription, email our sales.


Release notes

15.1 (2024-01-08)

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.reg.rejectNonTLSRedirectionURIs -- The configuration property is extended to apply to native applications (OAuth 2.0 clients registered with application_type set to native). Previously it applied only to web applications (clients registered with application_type set to web). The default value remains true (non-TLS web host URLs rejected).

Resolved issues

  • Configured custom scope value to claim name mappings (op.claims.map.*) must be observed when processing prompt=none and equivalent OpenID authentication requests (issue server/961).

  • Processing of OAuth 2.0 authorisation and OpenID authentication requests is hardened to ignore query parameters with illegal escape sequences in the query parameter name or value. Previously such illegal escape sequences in the query string would produce an unchecked exception resulting in an HTTP 500 Server Error in the authorisation session start (POST) request (issue server/958).

  • Logs an OP1202 INFO message whenever the SSO for an end-user is disabled due to the requesting client matching the optional op.sso.disableForSelectedClients configuration (issue server/959).

Dependency changes

  • Updates to com.nimbusds:oauth2-oidc-sdk:11.9.1

Connect2id server 15.0 upgrades to Java 17, adds a refresh token maximum idle timeout

2024 begins with a new major release of the Connect2id server which was in silent preparation for several months.

Runtime changes

The server is now built for Java 17, meaning the Java 11 runtime is no longer supported. The most recent Java LTS runtime, 21, has not been tested and therefore isn't marked as supported yet. We intend to test it once Apache Tomcat 11 with virtual threads support (project Loom) ships a stable release.

The Servlet APIs and related dependencies were also upgraded, to the latest Jakarta Servlet 6.0 API. This means that the Connect2id server will now require Apache Tomcat 10.1 to run. Tomcat 9, which is based on the older Java Servlet APIs, can no longer be used.

The c2id/c2id-server-min Docker image was updated to reflect this changes. Note that the stock image for Tomcat 10.1 has switched to the Eclipse Temurin Java SE build and uses Ubuntu Linux as the underlying Linux distribution. The older Tomcat 9 image was based on Amazon's Corretto image.

New refresh token capabilities

The refresh token in OAuth 2.0 enables client applications to receive a long-term credential for accessing protected resources. The credential can be issued with indefinite validity (and revoked when required), or issued with an a set expiration time. When the refresh token becomes invalidated, due to revocation or end of its lifetime, the client application can no longer use it at the token endpoint, indicated by an invalid_grant error, which means the end-user must be asked to authorise the client again.

This Connect2id server release introduces an additional time dimension to refresh tokens -- the ability to set an maximum idle time.

Refresh token max idle time

By configuring the refresh tokens for a client with a suitable maximum idle time, a session for the client and the end-user is established at the token endpoint. As long as the client keeps using the refresh token it will remain valid and will grant the issue of new access tokens. When use of the refresh token stops, due to the end-user leaving the client application or due to inactivity, and the maximum idle time is reached, the refresh token becomes invalidated. In order to continue use of the application, the end-user must re-authenticate and re-authorise the client (unless the consent was persisted).

This new refresh token property is set using the optional refresh_token.max_idle parameter of the consent object. The value is expressed in seconds, with zero being the default and meaning no maximum idle time.

Example setting of a 1 hour idle time:

{
  "scope"         : [ "openid", "email" ],
  "claims"        : [ "email", "email_verified" ],
  "refresh_token" : { "issue"    : true,
                      "max_idle" : 3600 }
}

The maximum idle time and be combined with a lifetime limit of the refresh token. The refresh token will become invalidated when one or the other timeout occurs. The maximum idle time should be shorter than the lifetime limit.

Example setting of a 1 week lifetime limit and a 1 hour idle time for the refresh token:

{
  "scope"         : [ "openid", "email" ],
  "claims"        : [ "email", "email_verified" ],
  "refresh_token" : { "issue"    : true,
                      "lifetime" : 604800,
                      "max_idle" : 3600 }
}

New refresh_token_expires_in token response parameter

The token response of the Connect2id server was also updated and will now include a refresh_token_expires_in parameter, whenever a refresh token with a lifetime limit is issued. Refresh tokens that don't have a lifetime limit, or have maximum idle time only, will not include this parameter. A client may use this hint to make an authorisation request to the Connect2id server ahead of the refresh token expiration.

{
  "access_token"             : "vJkbPNUFaK4kVIMGQlEmyA.-MAquq_5yQqtae62b8i7aw",
  "token_type"               : "Bearer",
  "expires_in"               : 600,
  "scope"                    : "openid email",
  "refresh_token"            : "eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUl...",
  "refresh_token_expires_in" : 604800
}

The invalid_grant error code remains the standard and recommended method for clients to detect when the refresh token has become invalid, due to expiration or revocation.

Access token lifetime guarantees

The refresh token as an OAuth grant is used to mint new access tokens and when it's given a certain time limit descendant access tokens should not exceed it.

This can occur when a refresh token that is configured for expiration approaches it end of life, which may then become shorter that the configured access token lifetime. To prevent this from occurring the Connect2id server will automatically trim the access token lifetime to the (remaining) lifetime of the refresh token, or the maximum idle time of the refresh token (whichever is shorter).

The above token example token response may get modified as follows when the remaining refresh token lifetime becomes shorter than the originally configured access token lifetime of 600 seconds:

{
  "access_token"             : "vJkbPNUFaK4kVIMGQlEmyA.-MAquq_5yQqtae62b8i7aw",
  "token_type"               : "Bearer",
  "expires_in"               : 550,
  "scope"                    : "openid email",
  "refresh_token"            : "eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUl...",
  "refresh_token_expires_in" : 550
}

Refresh token introspection updates

The Connect2id server resource for inspecting refresh tokens will now provide a more exact picture of the token. The rti (refresh token issue time) will be reported consistently for both refresh tokens linked to long-lived authorisations as well as self-contained (JWT-encoded) refresh tokens linked to transient authorisations. The rtl (refresh token lifetime) will report the actual remaining token lifetime, relative to the refresh token issue time, rather than the originally configured. The new refresh token maximum idle time property is going to appear as rtm when set.

Connect2id server SDK

The current Connect2id server SDK version is now 5.1. Starting with v5.0 it is being built with Java 17, which becomes the minimum JDK requirement for developing new server plugins in future.

The RefreshTokenSpec was updated to support the new max_idle parameter.

There are no breaking changes in the server SDK, save for InitContext.getServletContext. which will now return a jakarta.servlet.ServletContext instead of a javax.servlet.ServletContext. This interface method is rarely used, but if you do happen to have a plugin that relies on it update it accordingly to the new Jakarta Servlet 6.0 API.

Other changes and fixed bugs

The op.idToken.ignoreUserInfoError configuration property was deprecated. If you rely on it to require ID token issue to fail on claims source exceptions use the new op.idToken.ignoreClaimsSourceErrors instead.

The SQL connection pool metrics will now be published under the sqlStore.pool.* prefix, rather than taking the name of the first Infinispan map / cache as the prefix, for ease and consistency.

A handful of bugs, some more serious, some less (but none critical) were also fixed in this release. You can find detailed information in the release notes below.

Upgrading to Connect2id server 15.0

  1. Make sure the new Connect2id server is deployed in a Java 17 runtime.

  2. Make sure the Servlet container is Jakarta Servlet 6.0 compliant. The compliant Apache Tomcat version is 10.1.

  3. Database schema changes:

    This new release requires an upgrade to the SQL database schema of existing deployments.

    In order to support the new max_idle refresh token property the long_lived_authorizations SQL table, part of the Connect2id server authorisation store, received a new rtm column. The schema upgrade will be performed automatically for existing deployments, on Connect2id server 15.0 startup, unless the server is intentionally configured with dataSource.createTableIfMissing=false, in which case the column addition to upgrade the table schema must be done manually.

    All SQL table definitions can be found in /WEB-INF/sql/create-table-statements-*.sql, where * identifies the database type, e.g. postgres95 for PostgreSQL.

    Deployments with DynamoDB, which is essentially a schema-less database, do not require a schema upgrade operation.

Download 15.0

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 15.0: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: 7ca4a6699ed7bc014069ae1d830cbd28f706e81987c427ad834e8e6fea1f407c

Connect2id server 15.0 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: 7d02b3f3bae9988815c340c9c49b69a1a28ecdc53c87118ff713dc58191ceab7

Multi-tenant edition

Apache Tomcat package with Connect2id server 15.0: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: 75f15bff04792af288e6669e1e254f2acc2c5c04c4f9ef1d5ba53308e0274127

Connect2id server 15.0 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 26b2d23114a17999e31bfba27cb3aa3893b1d9c62b8b284373ea4bb610301e2f

Questions?

For technical questions about this new release contact Connect2id support. To purchase a production license for the Connect2id server, renew or upgrade your support and updates subscription, email our sales.


Release notes

15.0 (2024-01-02)

Summary

  • Upgrades to Java 17.

  • Upgrades to Jakarta Servlet 6.0 and Jakarta JAX-RS 3.1. The minimum supported Apache Tomcat version becomes 10.1.x.

  • The Connect2id server SDK (v5.0) is upgraded to Java 17 and Jakarta Servlet 6.0. Plugins that retrieve a ServletContext from the InitContext interface will receive a jakarta.servlet.ServletContext instead of a javax.servlet.ServletContext.

  • Refresh tokens issued by the Connect2id server can be optionally set to expire after a period of idle time, expressed in seconds. This enables an identity provider to establish a session for a given end-user and client application, with the refresh token remaining active as long as the client keeps using it frequently enough to obtain new tokens. When use of the refresh token stops, due to the end-user leaving the client application, and the maximum idle time is reached, the refresh token becomes invalidated. The client application must make a new authorisation request, to log in the end-user and / or obtain their consent, in order to receive a new refresh token.

    The refresh token maximum idle time is settable per end-user and / or client, can be applied to both regular and rotated refresh tokens, and is disabled by default. The refresh token maximum idle time is independent of the optional refresh token lifetime setting, and should not exceed it.

  • For token responses containing an access and refresh token, the lifetime of the access token will be automatically trimmed so that it doesn't exceed the maximum idle time or lifetime of the refresh token, whichever is shorter.

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.idToken.ignoreClaimsSourceErrors -- New optional configuration property, deprecating the existing op.idToken.ignoreUserInfoError which will be removed in a future major Connect2id server release.
  • /WEB-INF/infinispan-*-{mysql|oracle|postgres95|sqlserver}.xml

    • Sets the HikariCP property "poolName" to sqlStore so that all SQL connection pool related metrics appear under the sqlStore.* prefix instead of the name of the first declared Infinispan map / cache (sessionStore.subjectMap in the regular Connect2id server edition, or tenantRegistry.tenants in the multi-tenant Connect2id server edition).

    • Upgrades the SQL schema by adding a new rtm (refresh token maximum idle time) column to the long_lived_authorizations table. In existing deployments the Connect2id server will automatically add the new column on startup, unless dataSource.createTableIfMissing is disabled.

Web API

  • /authz-sessions/rest/v3/

    • The consent object receives a new optional refresh_token.max_idle parameter. May be used to specify a maximum idle time, in seconds, for the issued refresh token. If the refresh token is not used within this time period the Connect2id server will invalidate it due to inactivity. The default value is 0 (no idle time expiration).
  • /direct-authz/rest/v2

    • The request object receives a new optional refresh_token.max_idle parameter. May be used to specify a maximum idle time, in seconds, for the issued refresh token. If the refresh token is not used within this time period the Connect2id server will invalidate it due to inactivity. The default value is 0 (no idle time expiration).
  • /token

    • The token response will include a refresh_token_expires_in parameter for responses that contain a refresh token that is set to expire. When present the value is a positive integer indicating the number of seconds until the refresh token expiration, similar to the standard access token expires_in parameter. Responses with refresh tokens that don't have a maximum lifetime set will not include this parameter. Clients can use this parameter as a hint when to make a new request to the Connect2id server authorisation endpoint. The invalid_grant error code remains the standard and recommended method for clients to detect when the refresh token has become invalid, due to expiration or revocation.

    • For token responses with an expiring refresh token, the lifetime of the issued access token is guaranteed to never exceed the lifetime or the maximum idle time of the refresh token. If the lifetime of the access token would exceed the refresh token lifetime or maximum idle time, it will be automatically trimmed to achieve expiration parity with the refresh token.

  • /authz-store/rest/v3/authorizations

    • The OAuth 2.0 / OpenID Connect authorisation object receives a new optional rtm member, representing the refresh token maximum idle time, in seconds. The default value is 0 (no idle time expiration).
  • /monitor/v1/metrics

    • All SQL store Hikari connection pool metrics are now published under the sqlStore.pool.* prefix. The [infinispan-cache-name].sqlStore.pool.* prefix is no longer used.

SPI

  • Upgrades the Connect2id server SDK to com.nimbusds:c2id-server-sdk:5.1

    • Upgrades to Java 17.

    • The InitContext.getServletContext() method returns jakarta.servlet.ServletContext instead of javax.servlet.ServletContext (breaking change).

    • The ServletInitContext constructor accepts jakarta.servlet.ServletContext instead of javax.servlet.ServletContext (breaking change).

    • The RefreshTokenSpec adds support for setting a maximum idle time for the refresh token.

Resolved issues

  • Fixes the HTML representation of the static pages for HTTP 404, 405, 500 and all other errors that aren't handled by the web application (issue server/953).

  • Removes support for legacy cnf.x5t encoding in access tokens issued by Connect2id server 7.x and older releases (issue authz-store/229).

  • The access token lifetime must be automatically trimmed to match the lifetime or the remaining lifetime of the refresh token (for expiring refresh tokens)(issue authz-store/228).

  • The rtl (refresh token lifetime) value of authorisation objects returned by the authorisation store web API must reflect the remaining lifetime in respect to rti (refresh token issue time) when the refresh token was configured for rotation (issue authz-store/224).

  • The rti (refresh token issue time) value for long-lived authorisation objects with configured rotation must be updated after a refresh (issue authz-store/224).

  • The expiration time of self-contained (JWT-encoded) refresh tokens must not be advanced when the refresh token is set for rotation and a new refresh token is returned at the token endpoint in response to a refresh token grant (issue authz-store/225).

  • Removes the /client-reg/* endpoint alias to /clients/* that was deprecated in Connect2id server 3.0 (2015-03-26) (issue server/911).

  • Removes the authorisation store and session banner pages (issue server/763).

  • The SQL store ExpiredEntryPagedReaper must log the IS0128 debug message in all execution paths (issue sql-store/37).

  • Fixes the Infinispan metadata recreation for authorisation code entries persisted to an SQL database. The bug was introduced in Connect2id server 9.1.1 in response to issue authz-store/176 and caused expired entries to remain persisted in the "pending_codes" table (issue authz-store/230).

Dependency changes

  • Upgrades to com.nimbusds:c2id-server-sdk:5.1

  • Updates to com.nimbusds:oauth2-oidc-sdk:11.9

  • Updates to com.nimbusds:c2id-server-property-source:2.0

  • Updates to com.nimbusds:tenant-manager:9.0.2

  • Updates to com.nimbusds:tenant-registry:9.0

  • Upgrades to com.nimbusds:oauth2-authz-store:26.2.1

  • Upgrades to com.nimbusds:oidc-session-store:17.1

  • Updates to com.nimbusds:oauth-grant-handlers-web:2.0

  • Updates to com.nimbusds:nimbus-jwkset-loader:6.0

  • Updates to com.nimbusds:content-type:2.3

  • Upgrades to com.nimbusds:common:3.0.3

  • Updates to com.thetransactioncompany:cors-filter:3.0

  • Updates to Infinispan 14.0.21.Final

  • Updates to com.nimbusds:infinispan-cachestore-common:4.0

  • Updates to com.nimbusds:infinispan-cachestore-sql:8.1.1

  • Updates to com.nimbusds:infinispan-cachestore-dynamodb:6.0

  • Updates to com.nimbusds:infinispan-cachestore-redis:11.0

  • Upgrades to Jakarta Servlet API 6.0.0

  • Upgrades to JAX-RS 3.1

  • Upgrades to Jersey 3.1.4

  • Updates to DropWizard Metrics 4.2.23

  • Updates to commons-io:commons-io:2.15.0

  • Updates to org.apache.commons:commons-compress:1.24.0

  • Updates to org.mariadb.jdbc:mariadb-java-client:2.7.11