Connect2id server 15.5

2024-04-23

This Connect2id server release updates the plugin interface for sourcing user claims (attributes). It also adds a special configuration to mitigate false token revocation positives due to timing issues.

Consented scope hint in the claims source SPI

The Connect2id server comes with a plugin interface for sourcing user claims, such as contact details, profile information and entitlements. These claims are then fed into UserInfo responses, ID tokens or access tokens, subject to consent.

To aid decisions in claims source plugins, the Connect2id server is now going to make the associated consented scope available with each request to the claims source. If you implement your own SPI plugin the scope can be obtained via the new ClaimsSourceRequestContext.getScope method. If you use a web hook it will appear in the optional scope parameter, which must first be enabled.

Example request:

POST /claims-source HTTP/1.1
Host: www.example.com
Content-Type: application/json; charset=UTF-8
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6

{
  "iss"              : "https://c2id.com",
  "sub"              : "alice",
  "claims"           : [ "email",
                         "email_verified",
                         "name",
                         "given_name",
                         "family_name" ],
  "scope"            : [ "openid",
                         "email",
                         "profile",
                         "offline" ],
  "claims_transport" : "userinfo"
}

More information how the scope gets determined for a particular claims request can be found in the ClaimsSourceRequestContext JavaDoc and the release notes below.

Note that the scope is intended only as a hint in plugin logic. Claims will continue getting sourced by providing an explicit list of their names, regardless of the consented scope value. That's because end-users may not consent to all claims that expand from a certain scope value. Claims can also be requested individually, with a scope value like email or profile, using the claims OpenID authentication request parameter.

Revocation timestamp check bias

The Connect2id server provides an API where clients, end-user access and their tokens can be revoked. POSTed revocations are given a timestamp and recorded in the server's database. Whenever a token is inspected, the server checks for any recorded revocations after the token issue time (iat). If a revocation is found the token is considered invalid.

After a typical revocation the end-user must log in and give their consent again in order for the client application to regain access. In special scenarios where this is done by an automated process the token revocation and subsequent new token issue may occur at the same second. Due to the second resolution of token and revocation timestamps, this can lead to timing issues, for example in clusters where the clocks of the computers are out of sync. To mitigate such issues deployments can adjust the "bite" point of revocation time checks with a special new configuration:

authzStore.revocation.checkBias

Its documentation has hints when and how to use it. If in doubt leave it at its default value (zero bias).

Dependency updates

A range of dependencies were updated, including the BouncyCastle JCA provider to 1.78. The BouncyCastle update clears several reported CVEs, none of them critical for Connect2id server operation.

Download 15.5

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: 5fae4e5c8201ec0f72dba96c78724dff702fdeb2a30eb7b4f0159114afbd620f

Connect2id server 15.5 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: 9a4e6fa5e062cbe70d19c248966be3102d286f90836c6fd1c8b39ae8d456dbd9

Multi-tenant edition

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

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

SHA-256: 1b89b280dd28094dede54eef43086c4139e913ceae2c803c39d77645202894b0

Connect2id server 15.5 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: fef049716b8773a47fa64d7436ed010883c15e99fc9faf4a44f1f2c9a9524335

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.5 (2024-04-23)

Configuration

/WEB-INF/authzStore.properties
- authzStore.revocation.checkBias -- New optional configuration property to adjust the checking of revocation timestamps by adding a negative or positive time bias, in seconds. The default value is 0 seconds (no bias).
  
  A token is deemed active (non-revoked) if there are no recorded revocations for the token subject and / or client ID after the token issued-at time ("iat"). The resolution of revocations and token issued-at times is in seconds.
  
  With no (zero) bias tokens issued at the same second when a revocation is recorded are considered active (non-revoked). This enables a subject and / or client ID to have its tokens revoked and then be immediately issued again with active tokens, within the same second.
  
  A positive bias of 1 ensures tokens issued within the same second of a revocation are considered revoked, preventing any ambiguity in the time sequence of revocation and token issue events. A bias greater than 1 should generally not be used.
  
  A negative bias can mitigate false revocation positives in a Connect2id server cluster where the clocks of the individual server instances are out of sync.
/WEB-INF/httpClaimsSource.properties
- op.httpClaimsSource.includeScope -- New optional configuration property of type boolean. Enables / disables inclusion in the request of the associated consented scope. Disabled by default.

SPI

Upgrades the Connect2id server SDK to com.nimbusds:c2id-server-sdk:5.3
- New ClaimsSourceRequestContext.getScope method that returns the associated consented scope:
  - When sourcing claims for a UserInfo endpoint response this is the scope of the access token.
  - When sourcing claims for an ID token to be returned at the token endpoint this is the scope of the OAuth 2.0 grant (such as an authorization_code or refresh_token grant).
  - When sourcing claims for an ID token to be returned at the authorisation endpoint (for a response_type that contains the id_token value) this is the scope of the end-user consent.
  - When sourcing claims for an ID token returned at the Connect2id server direct authorisation endpoint.
  - In all other cases the scope is not provided and will be null.

Resolved issues

The Connect2id server must reject op.claims.map.* configuration properties with id_token: and access_token: prefixed claim names. These prefixes are intended for use in the authorisation session API and other documented locations only, using them in a custom OpenID claims map can lead to unintended side effects (issue server/991).
The AS0214 log INFO message must be recorded at the start of a revocation (issue authz-store/233).

Dependency changes

Upgrades to com.nimbusds:c2id-server-sdk:5.3
Upgrades to com.nimbusds:oauth2-authz-store:26.3
Updates to com.nimbusds:oidc-session-store:17.4
Updates to com.nimbusds:oidc-claims-source-http:3.1
Updates to net.minidev:json-smart:2.5.1
Updates to BouncyCastle 1.78
Updates to com.google.crypto.tink:tink:1.13.0
Updates to commons-codec:commons-codec:1.16.1
Updates to commons-io:commons-io:2.16.1
Updates to Log4j 2.23.1

Connect2id server 15.4 introduces an STS web API to aid federated login

2024-03-11

This release of the Connect2id server ships the much anticipated Security Token Service (STS) web API to ease implementation of federated logins for identity providers. The concept of federated login enables an identity provider to call on 3rd party providers to authenticate end-users and obtain attributes about them, in a manner that is completely transparent to the client applications.

An identity provider that is built with the Connect2id server can now utilise the server's existing cryptographic facilities - JWT signing and key store - to mint JWTs to secure OAuth 2.0 flows with upstream OpenID providers. An upstream provider can verify the signature of a JWT using the public JWK set URL of the Connect2id server.

The first version of the STS API supports minting of tokens for the following purposes:

JAR -- For signed authorisation requests (JAR), as specified in RFC 9101, also called request objects in OpenID Connect.
private_key_jwt -- For JWT based client authentication at the token and other endpoints, using private key authentication.

To prevent mistakes in client logic, the STS API uses carefully designed templates to mint the requested JWTs. The templates take care to populate the JWT headers and claims sets with the correct data for the type of JWT and perform validation on the POSTed parameters. This means the STS cannot be used (or abused) to mint arbitrary JWTs.

Example request to the STS API to mint a token for a JAR:

POST /sts/rest/v1/issuer HTTP/1.1
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6
Content-Type: application/json

{
  "template"   : "JAR",
  "alg"        : "RS256",
  "aud"        : "https://op.example.com",
  "parameters" : {
      "response_type"         : "code",
      "client_id"             : "client-123",
      "redirect_uri"          : "https://rp.example.com/cb",
      "scope"                 : "openid",
      "state"                 : "Mu0niexo",
      "nonce"                 : "Baemie2F",
      "code_challenge"        : "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM",
      "code_challenge_method" : "S256"
  }
}

The STS will return a JWT, which when inspected will show a header and a claims set similar to these:

JWT header, note the typ (type) header to explicitly type the JWT, a security measure against cross-jwt confusion:

{
  "alg" : "RS256",
  "typ" : "oauth-authz-req+jwt",
  "kid" : "q9SZ"
}

JWT claims set, containing the requisite iss and aud claims, the rest are parameters of the signed OpenID authentication request:

{
  "iss"                   : "client-123",
  "aud"                   : "https://op.example.com",
  "response_type"         : "code",
  "client_id"             : "client-123",
  "redirect_uri"          : "https://rp.example.com/cb",
  "scope"                 : "openid",
  "state"                 : "Mu0niexo",
  "nonce"                 : "Baemie2F",
  "code_challenge"        : "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM",
  "code_challenge_method" : "S256"
}

What else has changed in this release can be found in the release notes below.

Download 15.4

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: 8b6f08c4ac9de28092e3139a511e684709ba97d071895bc795d9f7bb693bad5f

Connect2id server 15.4 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: d87932c45b635ac5c55380f8325c98ea841372c1be3b27d82094b16721c57242

Multi-tenant edition

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

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

SHA-256: 4034b1b9fa41e17feb45484648aac58bf893528172a14564570140682e9db0be

Connect2id server 15.4 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 880bb43a909834c9ea6ce465281b2a0b9b60541c0bea085baf8565f3b9a31475

Questions?

Release notes

15.4 (2024-03-11)

Summary

Adds a new Security Token Service (STS) web API to issue signed JWTs for JWT-secured Authorisation Requests (JAR, see RFC 9101) and private_key_jwt authentication. Intended when an Identity Provider based on the Connect2id server acts an OAuth 2.0 client / OpenID relying party in federated login scenarios. The signature of an issued JWT can be validated using the server JWK set published at the /jwks.json endpoint.

Configuration

/WEB-INF/oidcProvider.properties
- op.sts.apiAccessTokenSHA256.* -- New optional configuration property. Specifies a master access token for the STS web API, represented by its SHA-256 hash (in hexadecimal format). The hashed storage is intended to prevent accidental leakage of the token through configuration files, logs, etc. The token is of type Bearer, non-expiring and must contain at least 32 random alphanumeric characters to make brute force guessing impractical. If not specified the web API is disabled.
  
  Additional access tokens, to facilitate token roll-over or for other needs, can be configured by appending a dot (.) with a unique label to the property name, e.g. as op.reg.apiAccessTokenSHA256.1=abc....
/WEB-INF/log4j.xml
- Updates the PatternLayouts of the RollingFile and Console appenders to comply with a recent Log4j library change.

Web API

/sts/rest/v1/
- New Security Token Service (STS) web API. Enabled if it has a master API access token (op.sts.apiAccessTokenSHA256) configured.
/sts/rest/v1/issuer
- New resource to issue signed JWTs for JWT-secured Authorisation Requests (JAR) and private_key_jwt authentication. Supports the RSxxx, PSxxx and ESxxx JWS algorithm families. The JWTs are generated according to a built-in template that defines the acceptable JWT header parameters and claims set. The template ensures the JWT is compliant with the respective specification and potential errors, such as including a sub claim in signed request object (JAR), are prevented.
  
  Supported templates:
  - JAR -- For issue of signed JWT-secured Authorisation Requests (JAR), also called request objects in OpenID Connect.
  - private_key_jwt -- For issue of private key client authentication JWTs for use at the token and other endpoints of an OAuth 2.0 authorisation server / OpenID provider.

Resolved issues

Corrects the OP5109 log INFO message that records whether a master API token for the client registration endpoint is configured (issue server/978).
Fixes the shipped /WEB-INF/log4j.xml configuration to comply with a recent Log4j library change. In Connect2id server 15.3 this caused the log lines to contain only the log message (%m), with timestamp, etc. missing (issue server/980).
Logs token success response (OP6225) and error response (OP6226) at INFO level, with client ID, grant type and other details (issue server/982).

Dependency changes

Updates to org.slf4j:slf4j-api:2.0.9
Updates to com.github.dubasdey:log4j2-jsonevent-layout:0.0.8

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?

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?

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.5

Consented scope hint in the claims source SPI

Revocation timestamp check bias

Dependency updates

Download 15.5

Standard Connect2id server edition

Multi-tenant edition

Questions?

Release notes

15.5 (2024-04-23)

Configuration

SPI

Resolved issues

Dependency changes

Connect2id server 15.4 introduces an STS web API to aid federated login

Download 15.4

Standard Connect2id server edition

Multi-tenant edition

Questions?

Release notes

15.4 (2024-03-11)

Summary

Configuration

Web API

Resolved issues

Dependency changes

Connect2id server 15.3

Download 15.3

Standard Connect2id server edition

Multi-tenant edition

Questions?

Release notes

15.3 (2024-03-05)

Web API

Resolved issues

Dependency changes

OpenID Federation policies for Pairwise Pseudonymous Identifiers (PPID)

Connect2id server 15.2

Download 15.2

Standard Connect2id server edition

Multi-tenant edition

Questions?

Release notes

15.2 (2024-02-16)

Configuration

SPI

Resolved issues

Dependency changes

Topics

Contact