Connect2id server 15.3

2024-03-07

This Connect2id server release ships an update to the user sessions web API, to enable an individual session to be checked or retrieved without disturbing the session's max idle time expiration. To do this use the skip_last_used_update query parameter as shown in the example below:

GET /session-store/rest/v2/sessions?skip_last_used_update=true HTTP/1.1
Host: c2id.com
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6
SID: WYqFXK7Q4HFnJv0hiT3Fgw.-oVkvSXgalUuMQDfEsh1lw

This feature comes with a caveat. It is supported only in Connect2id server deployments that persist the sessions to a database or Redis. The query parameter will be ignored and have no effect in deployments configured for in-memory session storage and replication clustering.

A session related fix and improvements under the hood also took place.

About 20 dependencies across the board were bumped. The PostgreSQL JDBC driver was bumped to clear a critical CVE-2024-1597 that has been reported for the driver. The Connect2id server is not using the vulnerable JDBC configuration parameter, so deployments have not been affected.

Detailed information about the new release can be found in the notes below.

Download 15.3

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: 8b88a8ece68a9974c52d01fbbfb279c1ac4b01e9f7fc2eb3e4ce2c3c630f2801

Connect2id server 15.3 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: f7df8e8523d489e0d321e7c8510b5daf370b86c5779ac26e8864223cf8241ce1

Multi-tenant edition

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

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

SHA-256: 247207bef28058874ab8cf705fad3b668953d4848416e74f0082d897dc3b0f74

Connect2id server 15.3 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: dd81b293433e65df9f9db83bcafdbbeb6964187025ee454915be2938493885f3

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.3 (2024-03-05)

Web API

• /session-store/rest/v2/

  • The sessions resource receives a new optional skip_last_used_update query parameter for GET requests for individual subject sessions. When true the internal timestamp that records the last session use will not be updated, leaving the session maximum idle time expiration unaffected. When false the last used timestamp of the session will be updated. The default value is false. Only Connect2id server deployments that persist the subject sessions to a database or Redis can skip the update of the session last used timestamp. In deployments using Infinispan in-memory replication clustering the query parameter will be disregarded and have no effect.

Resolved issues

• Updates the SQL store connector to log the SQL transaction isolation level at INFO level at Connect2id server startup. The log message receives the IS0143 identifier (issue sql-store/38).

• Removes a redundant ConcurrentMap.remove call in the subject session store when updating the last used timestamp of a retrieved persisted subject session with a positive max_idle value (issue session-store/97).

• Improves the performance of the authorisation session web API, the authorisation code grant processing, the refresh token grant processing and the token introspection processing by skipping the last used timestamp update of retrieved subject sessions where appropriate (issue server/975).

• Adds a org.apache.logging.log4j:log4j-slf4j-impl dependency to enable jOOQ query logging at DEBUG level (issue server/976).

Dependency changes

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

• Updates to com.nimbusds:oauth2-authz-store:26.2.2

• Updates to com.nimbusds:oidc-session-store:17.3

• Updates to Infinispan 14.0.24.Final

• Updates to Jersey JAX-RS 3.1.5

• Updates to com.google.guava:guava:32.1.3-jre

• Updates to commons-io:commons-io:2.15.1

• Updates to commons-codec:commons-codec:1.16.0

• Updates to Dropwizard Metric 4.2.25

• Updates to Log4j 2.23.0

• Updates to org.kohsuke.metainf-services:metainf-services:1.11

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

• Updates to com.h2database:h2:2.2.224

• Updates to org.postgresql:postgresql:42.7.2

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

• Updates to com.microsoft.sqlserver:mssql-jdbc:12.6.1.jre11

• Updates to com.oracle.database.jdbc:ojdbc11:21.13.0.0

• Adds org.apache.logging.log4j:log4j-slf4j-impl:2.23.0

• Removes org.apache.commons:commons-compress:1.24.0

OpenID Federation policies for Pairwise Pseudonymous Identifiers (PPID)

Vladimir Dzhuvinov / Connect2id · 2024-02-26

How to mandate identity providers in a OpenID Federation to issue ID tokens and UserInfo responses with pairwise pseudonymous identifiers (PPID)? And how to make the PPIDs in a federation share the same sector identifier?

This question was raised in the OpenID Federation issue tracker. PPIDs are crucial in federations built around the privacy-by-default principle.

A standard for federating entities, such as OpenID providers and relying parties, must be neutral in regard to the protocols that the entities use among themselves. Neutrality separates the concerns of the federation infrastructure from those of the application protocols. It makes it easier to reason about systems, which is also good for security. The internet protocol is good example of neutrality. Its purpose is to relay datagrams and it's not concerned with their content.

If a particular federation has some requirement on an identity or application protocol in its jurisdiction, the OpenID Federation standard provides a simple and flexible tool to express that, called metadata policies. The use of metadata policies in a federation is optional.

A federation operator can mandate PPIDs by placing the following policy at the trust anchor level:

"metadata_policy": {
  "openid_provider": {
     "subject_types_supported": { "value": ["pairwise"] }
  },
  "openid_relying_party": {
     "subject_type": { "value": "pairwise" }
  }
}

This will automatically cause the metadata of OpenID providers and relying parties in the federation to assume the necessary parameters for PPID issue.

Once set by an authority, the value policy operator guarantees that the metadata parameter cannot be changed or overridden by subordinate authorities in the federation and in trust chains.

An intermediate federation entity, for example a participating organisation with multiple relying parties, may choose to define a common sector ID URL for them, to ensure its applications receive an identical IDs for the same end-user.

"metadata_policy": {
  "openid_relying_party": {
     "sector_identifier_uri": { "value": "https://org.example.com/sector-ids.json" }
  }
}

When the openid_relying_party metadata policies in the trust chain for these entities get merged, the resulting policy will become this:

"metadata_policy": {
  "openid_relying_party": {
     "subject_type": { "value": "pairwise" },
     "sector_identifier_uri": { "value": "https://org.example.com/sector-ids.json" }
  }
}

A federation may choose to define a sector_identifier_uri at the top-level, in the trust anchor metadata, so that it applies to all OpenID relying parties, across all participating organisation. However, this may require some additional coordination or customisation, because OpenID Connect requires the sector ID URL to point to a JSON document that contains the redirect_uris of the OpenID relying parties:

The value of the sector_identifier_uri MUST be a URL using the https scheme that points to a JSON file containing an array of redirect_uri values. The values of the registered redirect_uris MUST be included in the elements of the array.

One work around, without breaking OpenID Connect, is to use the OpenID Federation web APIs to crawl the federation to collect the redirect_uris of all applications. If you study the OpenID Federation 1.0 spec you will likely be pleased by its powerful tools and APIs, so we shouldn't be surprised when one day it comes to replace X.509 and CAs, in a future TLS 2.0 standard.

Connect2id server 15.2

2024-02-16

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

2024-01-30

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

Vladimir Dzhuvinov / Connect2id · 2024-01-19

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?

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

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.

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 😁

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.

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.

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.

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.

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!

---

The slide deck in PDF: