Connect2id server 6.0 is here, supporting a wider range of backend DBs and with new OpenID Connect security features

2016-10-30

At long last, Connect2id server 6.0 is here, offering a wide choice of databases for persisting its data, plus a string of new features for apps with stringent securing requirements on OpenID Connect identity provisioning and single sign-on.

This is the most significant release of the Connect2id server since its inception in 2012, and we hope you'll enjoy it!

Support for SQL and Redis backends

Since day one the Connect2id server has relied on LDAP to persist its data, such as client registrations and sticky grants. This worked extremely well in practice, and the two LDAP databases that we recommend -- OpenLDAP and OpenDJ, proved highly reliable and capable, with deployments handling millions of user logins and token issues on a daily basis.

The range of the supported backends now includes three popular relational databases, plus Redis:

  • PostgreSQL 9.5+

  • MySQL 5.7.8+

  • H2 1.4+

  • Redis 2.8+, 3.0+ (incl. AWS ElastiCache with Redis)

Support for Redis was actually introduced in version 5.0.3 a week ago, to enable highly scalable OpenID provider deployments, where Redis assumes the role of a 2nd tier in-memory cache and store.

Out of the box the Connect2id server comes with an embedded H2 SQL database, which delivered impressive performance in single node server tests. To use a different database just switch the backend configuration.

The refactored persistence internals will make it easier for Connect2id engineers to add support for other backends in future. We've been pondering about Apache Cassandra and LMDB (simple file-based KV store, which can complement Infinispan with off-heap caching of Connect2id server data).

Encrypted ID tokens and UserInfo

Client applications can now be registered to receive ID tokens or UserInfo that are encrypted after signing. The elegant concept of JWT nesting permits this.

The Connect2id server supports all standard JWE algorithms for encryption:

  • Symmetric encryption: The ID token or UserInfo is encrypted with an AES key derived from the client_secret. The client can decrypt the cipher text by performing its own AES key derivation from the client_secret.

  • Asymmetric encryption: Also called public key encryption. The ID token or UserInfo is encrypted with an RSA or EC public key supplied by the client at registration time (via the jwks_uri or jwks registration parameters). Decryption is performed with the corresponding private key of the client.

Signed OpenID authentication requests

The OAuth 2.0 framework relies normally on the token endpoint to authenticate the requesting client app. The OpenID Connect option for signed authentication requests allows that to take place a step earlier in browser-based flows ( code and implicit), by putting the request parameters in a JWT. The JWT itself can be passed by value, or by URL reference.

Signed requests also allow selected request parameters, such as scope, to be locked down securely, for example at client registration time. This can be useful in situations when the application publisher and the relying party / client are separate entities (e.g. mobile apps distributed via a shop that register dynamically with the IdP / AS).

Client JWK set URLs

Clients that want to use their own RSA or EC keys for advanced JWT authentication with the server or to receive encrypted ID tokens and UserInfo can simply publish them in JSON Web Key (JWK) format at a HTTPS URL, and then register this URL with the Connect2id server. Previously client JWKs could only be registered statically, by value.

The server will cache the published keys so that processing of token requests doesn't get slowed down. Key-rollover will still be seamless: if the client ever updates its JWK set and uses a new key from it, the Connect2id server will automatically detect this and refresh the cached JWK set.

Pairwise identifiers

Pairwise identifiers promise enhanced privacy by making it harder for OpenID relying parties to correlate, or "link" user identities. This is achieved by providing each relying party with a different but consistent ID for the logged in user, while keeping the underlying real ID of the user confidential.

Example:

  • Alice has a user ID alice with the IdP.

  • Client A receives user ID z6rjKZ2jjGZ6JQyASLxzF5Fh1KUkv90-3aMZcXvyk4c for Alice.

  • Client B receives user ID kdbnJjGzk385mvIY_U6ml49ArpnE2yEcjFOJhDfLB7E for Alice.

  • Etc.

The Connect2id server implements pairwise IDs by applying deterministic encryption (AES with SIV) to the concatenation of the user ID and the sector ID. This allows the IdP to handle id_token_hint request parameters regardless of how the user ID type -- public or pairwise.

Here we must stress that pairwise IDs are not enough to prevent correlation of user identities across two or more clients. In order to achieve that all details released by the IdP for a given user that may facilitate linking must be made pairwise, such as email addresses. And even when all assertions about a user have been considered, correlation may still happen. Cem Paya discusses this at length in his blog post series on pairwise identifiers
(part 1, 2 and 3).

Revocation journal

The Connect2id server introduces a special journal to keep track of revocation events.

With that the effect of revocation is extended to issued access tokens. Previously, revocation was limited to deleting the long-lived authorisations and any associated refresh tokens that match the revocation spec (subject, actor, client_id).

In a next Connect2id server release the revocation journal may be made available for queries at the authz store web API, for audit purposes and also to enable syncing of the revocation events with resource servers.

Extra HMAC protection for session IDs, code and ID-based access tokens

An extra layer of cryptographic protection is added to browser session IDs, authorisation codes and identifier-based access tokens issued by the Connect2id server. This is done by appending a SHA256-based authentication code (HMAC) to them.

The HMAC extra allows the IdP to differentiate between expired and invalid browser session IDs, and raise an alarm if the latter is detected (may be a sign of a online SID guessing attack). The Connect2id server will proceed to lookup the SID in the underlying session store only if the HMAC check has passed.

The HMAC also provides protection in the event of a failure or compromise of the secure random generator on the host machine.

New serialisation

Serialisation of the Connect2id server objects in Infinispan was revised and updated to permit seamless introduction of new object fields in future.

The updated object serialisation means that a direct rolling upgrade to 6.0 by simply adding new 6.0 nodes to your existing Connect2id server cluster won't work. If you need help with creating a migration plan for 6.0 get in touch with us.

Download

To download a ZIP package of Connect2id server 6.0:

https://connect2id.com/assets/products/server/download/6.0/Connect2id-server.zip

(SHA-1: 7053c7a6cf820c7468f29331a6a6a9a13006afe4)

https://connect2id.com/assets/products/server/download/6.0/c2id.war

(SHA-1: 3ec1fb23413a7a217392ead8e96a2b1204e23635)

Questions?

For any questions, write the comments section below or email our support team.


Connect2id server 6.0 release notes (2016-10-29)

General

  • Switches to Infinispan's store APIs to enable support of other Connect2id server backends besides LDAP, such as PosgreSQL, MySQL, H2, flat file storage, Redis, AWS Elasticache and AWS S3.

  • Adds support for ID tokens signed with EC DSA (ES256, ES384 and ES512).

  • Adds support for UserInfo JWTs signed with EC DSA (ES256, ES384 and ES512).

  • Adds support for encrypted ID tokens. A client can receive ID tokens encrypted with a public RSA or EC key it has registered with the Connect2id server (via the jwks or jwks_uri client registration parameter), or with a symmetric AES key derived from its client_secret.

  • Adds support for encrypted UserInfo. A client can receive UserInfo JWTs encrypted with a public RSA or EC key it has registered with the Connect2id server (via the jwks or jwks_uri client registration parameter), or with a symmetric AES key derived from its client_secret.

  • Adds support for registering OpenID Connect / OAuth 2.0 clients with a JWK set specified by URI (jwks_uri). Intended for handling private_key_jwt client authentication, self-issued JWT and SAML 2.0 bearer grants, signed request objects, encrypted ID tokens and encrypted UserInfo responses. The downloaded client JWK set is cached by the Connect2id server to ensure quick processing of requests that rely on remote JWKs.

  • Updates handling of the optional max_age OpenID authentication request parameter. If max_age is set to zero (max_age=0) the Connect2id server will prompt the end-user for (re)authentication, even if the end-user has an existing valid session with the Connect2id server. This is equivalent to setting the optional prompt OpenID authentication request parameter to login (prompt=login). See issue #993 with the OpenID Connect working group (https://bitbucket.org/openid/connect/issues/993).

  • Adds support for pairwise subject (end-user) identifiers, based on deterministic AES encryption in SIV mode (see RFC 5297).

  • Adds an extra layer of security to issued session IDs, authorisation codes and identifier-based access tokens by provisioning them with a SHA-256 based Message Authentication Code (MAC) (truncated to 128 bits). The HMAC enables detection of online guessing attacks and may also be used to block certain DoS attacks the utilise the above objects.

  • Switches to new JSON-based marshalling of Connect2id server objects stored in Infinispan.

  • Provides claims sources and custom OAuth 2.0 grant handlers with access to the Infinispan cache manager to enable custom cache / map creation (issue server/234).

  • Refines diagnostic messages on a client registration error due to invalid or inconsistent client metadata.

  • Refines logging of invalid client authentication attempts at the token endpoint (issue server/199).

Configuration

  • /WEB-INF/jwkSet.json

    • All JSON Web Keys (JWKs) in the Connect2id server JWK set must have a key identifier ("kid" JWK parameter) and specify the intended key use ("use" JWK parameter).

    • All RSA JWKs intended for signing of objects (ID tokens, UserInfo JWTs and self-contained access tokens) must have their use parameter set to "sig" (signature). Required to prevent mix up with future RSA JWKs intended for encrypting objects to the Connect2id server.

    • Adds support for optional EC JWKs with curves P-256, P-384 and P-521 for signing of ID tokens and UserInfo JWTs. The EC JWKs must have a key identifier ("kid" JWK parameter) and be flagged for specify signature use ("use":"sig").

    • All AES JWKs intended for symmetric encryption of self-contained access tokens must have their use parameter set to "enc" (encryption). Required to prevent mix up with the introduced secret JWKs for HMAC protection and pairwise subject encryption (see below).

    • Adds new secret JSON Web Key (JWK) with ID "hmac" and use "sig" to facilitate HMAC-SHA256 protection of session IDs, authorisation codes and identifier-based access tokens. The HMAC key size must be 256 bits.

    • Adds new symmetric JSON Web Key (JWK) with ID "subject-encrypt" to facilitate AES SIV-mode (RFC 5297) encryption of pairwise subject identifiers. The accepted AES key sizes are 128, 192 and 256 bits.

  • /WEB-INF/oidcProvider.properties

    • Extends the op.idToken.jwsAlgs configuration setting to include support for ID tokens signed with EC DSA (ES256, ES384 and ES512).

    • Adds new op.idToken.jweAlgs configuration setting for the enabled JWE key management algorithms for applying optional additional encryption to issued ID tokens. All standard symmetric and public key JWE algorithms are supported: RSA1_5, RSA-OAEP, RSA-OAEP-256, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW, dir, A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW and A256GCMKW.

    • Adds new op.idToken.jweEncs configuration setting for the enabled JWE content encryption methods for applying optional additional encryption to issued ID tokens. All standard JWE methods are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512, A128GCM, A192GCM and A256GCM.

    • Adds new op.authz.requestJWSAlgs configuration setting for the accepted
      JWS algorithms for signed OpenID authentication requests passed with the optional request_uri or request parameter. The following JWS algorithms are supported: HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 and none.

    • Adds new op.reg.resourceRetriever.httpConnectTimeout configuration setting for the HTTP connect timeout (in milliseconds) when retrieving client resources (JWK sets and request objects specified by URI). Zero implies no timeout. Defaults to 250 ms.

    • Adds new op.reg.resourceRetriever.httpReadTimeout configuration setting for the HTTP read timeout (in milliseconds) when retrieving client resources (JWK sets and request objects specified by URI). Zero implies no timeout. Defaults to 250 ms.

    • Removes the op.reg.preloadCache, op.reg.ldapServer.*, op.reg.ldapUser.*, op.reg.ldapDirectory.*, op.reg.customTrustStore.* and op.reg.customKeyStore.* settings for configuring an LDAP store for the OpenID Connect and OAuth client registration. Configuration of the client registration store is now assumed by the Infinispan.

    • Extends the op.userinfo.jwsAlgs configuration setting to include support for UserInfo JWTs signed with EC DSA (ES256, ES384 and ES512).

    • Adds new op.userinfo.jweAlgs configuration setting for the enabled JWE key management algorithms for applying optional additional encryption to issued UserInfo JWTs. All standard symmetric and public key JWE algorithms are supported: RSA1_5, RSA-OAEP, RSA-OAEP-256, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW, dir, A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW and A256GCMKW.

    • Adds new op.userinfo.jweEncs configuration setting for the enabled JWE content encryption methods for applying optional additional encryption to issued UserInfo JWTs. All standard JWE methods are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512, A128GCM, A192GCM and A256GCM.

  • /WEB-INF/authzStore.properties

    • Removes the authzStore.options.preloadCache, authzStore.ldapServer.*, authzStore.ldapUser.*, authzStore.ldapDirectory.*, authzStore.customTrustStore.* and authzStore.customKeyStore.* settings for configuring an LDAP store for the long-lived (persisted) OpenID Connect and OAuth authorisations. Configuration of the long-lived authorisations store is now assumed by Infinispan.

    • Adds new authzStore.options.discardedAttributes settings to list the optional authorisation attributes that are to be automatically discarded from new authorisation objects, in order to conserve cache memory and backend storage.

    • Adds the "iat" (issued-at) claim to the list of recommended JWT claims to include in self-contained access tokens. Required to facilitate correct inspection of revoked self-contained access tokens.

  • /WEB-INF/infinispan.xml

    • Updates all advanced externalisers for Connect2id server data stored in Infinispan. The externalisers are now declared programmatically, instead of using the Infinispan XML configuration.

    • Adds new "clients.remoteJWKSetCache" cache.

    • Replaces the "op.regCache" cache with "clients.registrationsMap".

    • Replaces the "op.regTokenCache" cache with "op.clientRegTokenMap".

    • Replaces the "authzStore.authzCache" cache with "authzStore.longLivedAuthzMap".

Web API

  • /.well-known/openid-configuration

    • Advertises support for pairwise subject identifiers (subject_types_supported).
  • /clients/

    • Supports registration of OAuth 2.0 and OpenID Connect clients with a JWK set specified by URL (jwks_uri).

    • Supports registration of OpenID Connect clients for pairwise subject identifiers. OpenID Connect clients can be registered for pairwise subject identifiers by setting the "subject_type" parameter to "pairwise"; if more than one redirection URI is specified in the "redirect_uris" parameter, a "sector_identifier_uri" parameter must also be provided.

  • /session-store/rest/v2/sessions

    • Support for the optional "SID" header parameter on POST new session is removed, due to the introduction of HMAC secured session IDs. The key portion of the session ID can be set with the new "SID-Key" header parameter; the Connect2id server will then return the final SID (session key with appended HMAC).
  • /authz-store/rest/v2/revocation

    • Extends the effect of revocation to issued access tokens as well. Previously, revocation was limited to deleting the long-lived authorisations and any associated refresh tokens that match the revocation spec (subject, actor, client_id).
  • /authz-store/rest/v2/inspection

    • Access tokens that fall under the scope of a previous revocation event will be resolved as invalid. Previously, access tokens will appear as valid until they expire, unless the access token is identifier-based and had been explicitly revoked.
  • /monitor/v1/metrics

    • Replaces the "authzStore.numCachedAuthorizations" metric with "authzStore.numLongLivedAuthorizations".

    • Adds new "clientStore.numCachedRemoteJWKSets" metric for the number of cached client JWK sets.

Bug fixes

  • Adds check to prevent client registration of redirect_uris with a fragment component (issue sdk/188).

  • Fixes NPE in the LDAP connector when the asynchronous LDAP result listener receives a notification before the associated timer context is cached (issuer authz-store/117).

  • Fixes Log4j class loading conflict caused by shadowing of Log4j by the Infinispan Embedded package (iss #219).

  • Enables stack trace logging on Infinispan cache manager launch failure.

Dependencies

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

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

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

  • Upgrades to com.nimbusds:oauth2-oidc-sdk:5.17.2

  • Upgrades to com.nimbusds.nimbus-jose-jwt:4.27

  • Upgrades to org.bouncycastle:bcprov-jdk15on:1.55

  • Upgrades to com.nimbusds:common:2.1

  • Upgrades to Infinispan 8.2.4.Final

  • Upgrades to JAX-RS Jersey 2.23.2

  • Upgrades to com.unboundid:unboundid-ldapsdk:3.2.0

  • Upgrades to Log4j 2.6.2

  • Adds JHades dependency to diagnose class loader issuer at runtime (issue server/219).

Connect2id server 5.0.3 introduces support for Redis as 2nd level in-memory store

2016-10-21

Second level in-memory store with Redis / AWS ElastiCache

With this release we are introducing support for deploying the Connect2id server with Redis as a 2nd level in-memory store. You may benefit from this if you're operating an IdP or SSO service with more than 10M users.

Since its 1.0 release in 2014 the Connect2id server has utilised Infinispan to provide caching and in-memory storage (on the JVM heap) for a number of objects that an OpenID provider needs to handle, such as user sessions, sticky authorisations and client registrations. If high availability is required or a large user base needs to be serviced the way to handle that is by launching additional Connect2id server nodes, and let Infinispan replicate (or distribute) the in-memory data across them.

Such a cluster setup can work reasonably well, provided there are sufficient free resources (free JVM memory and CPU time) on each node to accommodate critical cluster topology events, such as a node failing (or being taken offline), or one or more nodes joining to respond to a sudden spike in demand. If the free JVM memory on one or more nodes is low, topology changes may cause significant cluster instability, leading to slower IdP response times. To stay away from such trouble make sure you periodically monitor the available memory on your JVMs and add new nodes preemptively. Long GC pauses can also become a problem with 16+ GB heaps, so when setting up a Connect2id cluster, choose in favour of having more nodes with less RAM, than fewer nodes but with more RAM.

The introduction of Redis as a 2nd level cache / in-memory store now make it much easier to scale a Connect2id server cluster up and down, and importantly, to do that independently from the main underlying in-memory store.

How is such a cluster set up?

  • Connect2id server tier -- Two or more Connect2id servers where Infinispan is configured in the lightweight invalidation mode, meaning that between themselves the server nodes only emit messages to indicate that a particular object key has been deleted or updated, so that the other nodes can clear
    (invalidate) it if they cache a local copy of it. Actual data is not moved between the Connect2id server nodes.

  • Redis tier -- Provides the underlying (authoritative) caching and in-memory storage of objects. If a Connect2id server node does not find an object in its own cache, it will try to load it from Redis (and then the database, if the type of object is persisted).

We have provided a sample Infinispan configuration file for using Redis as a 2nd level in-memory store on AWS in the Connect2id server package:

WEB-INF/infinispan-redis.xml

To override the default Redis server settings set the following Java system properties:

  • redisHost to point to your Redis server hostname / IP address
  • redisPort to point to your Redis server port (6379)

You can also edit these in the Infinispan config XML itself.

Important: Make sure the Redis database is not shared with other apps, and that no extraneous keys exist in buckets 1 through 9!

JBoss support

We also tweaked the server configuration a bit to permit deployment on JBoss 7 (and possibly other versions as well).

Other updates

Several components have also been updated, most notably Infinispan to v8.2.4.

Download

To download a ZIP package of Connect2id server 5.0.3:

https://connect2id.com/assets/products/server/download/5.0.3/Connect2id-server.zip

As WAR package only:

https://connect2id.com/assets/products/server/download/5.0.3/c2id.war

Questions?

Get in touch Connect2id support, we'll be delighted to help out.


Release notes

5.0.3 (2016-10-21)

General

  • Supports deployment to JBoss AS 7.

  • Supports Redis second level Infinispan in-memory / cache store.

  • Supports Infinispan map / cache clustering in invalidation mode.

Configuration

  • Adds sample infinispan-redis.xml configuration for using Infinispan in invalidation mode and Redis as shared second level in-memory store / cache.

  • Adds JBoss AS 7 deployment profile.

Web API

  • No changes

Bug fixes

  • None

Dependencies

  • Upgrades to Connect2id Session Store 4.0.5.

  • Upgrades to Connect2id Authorization Store 4.6.

  • Upgrades to Infinispan 8.2.4.Final.

  • Upgrades to Jersey JAX-RS 2.23.2.

  • Upgrades to UnboundID LDAP SDK 3.2.0.

The OpenID Connect server adds support for SQL backends

2016-09-29

The upcoming 6th release of the Connect2id server introduces support for SQL databases for persisting its own data, such as client registrations and authorisations. With this preview you can now test drive the server with a MySQL database.

  1. Download the ZIP file and unpack it.

  2. Provision a fresh MySQL database, and an account for it that the Connect2id server can use.

  3. Edit /webapp/WEB-INF/infinispan-mysql.xml in the c2id.war:

    • Set the dataSource.url properties to point to the MySQL database.

    • Set dataSource.user and dataSource.password to the user credentials for accessing the MySQL database.

  4. Start the LDAP directory with the sample users with opendj/bin/start-ds.

  5. Start the Tomcat web server with tomcat/bin/startup.sh.

  6. Point your browser to http://127.0.0.1:8080/oidc-client/ when the server has started.

That's it!

The Connect2id server will automatically create the required SQL tables if they are missing. The /WEB-INF/web.xml is also configured with a simple script that will create a demo OpenID client account for oidc-client with client_id 000123, so you can test drive OpenID Connect login.

To disable creation of this account (in production) simply comment out or delete the following lines from the /WEB-INF/web.xml descriptor:

<!-- Demo client registration installer (remove in production) -->
<listener>
    <listener-class>com.nimbusds.openid.connect.provider.demo.DemoClientRegInstaller</listener-class>
</listener>

You can also test drive the Connect2id server with a PostgreSQL 9.5 database. To do that edit /WEB-INF/web.xml to point to the Postgres specific Infinispan config like this:

<context-param>
    <description>
        The location of the Infinispan configuration file. Must be
        relative to the web application root directory.
    </description>
    <param-name>infinispan.configurationFile</param-name>
    <param-value>/WEB-INF/infinispan-postgres95.xml</param-value>
</context-param>

Then edit the data source parameters as explained above.

Download

To preview the upcoming Connect2id server 6.0 release download the following ZIP package and follow the instructions above, plus those in the README.txt file:

https://connect2id.com/assets/products/server/download/6.0-pre-4/Connect2id-server.zip

https://connect2id.com/assets/products/server/download/6.0-pre-4/c2id.war

Questions?

For any questions, write the comments section below or email our support team.


Release notes 6.0-pre-4 (2016-09-29)

General

  • Switches to Infinispan's persistent store APIs to enable support of other Connect2id server backends besides LDAP, such as MySQL, PosgreSQL, H2, flat file storage, Redis (experimental) and AWS Elasticache (experimental).

  • Adds support for ID tokens signed with EC DSA (ES256, ES384 and ES512).

  • Adds support for UserInfo JWTs signed with EC DSA (ES256, ES384 and ES512).

  • Adds support for encrypted ID tokens. A client can receive ID tokens encrypted with a public RSA or EC key it has registered with the Connect2id server (via the jwks or jwks_uri client registration parameter), or with a symmetric AES key derived from its client_secret.

  • Adds support for encrypted UserInfo. A client can receive UserInfo JWTs encrypted with a public RSA or EC key it has registered with the Connect2id server (via the jwks or jwks_uri client registration parameter), or with a symmetric AES key derived from its client_secret.

  • Adds support for registering OpenID Connect / OAuth 2.0 clients with a JWK set specified by URI (jwks_uri). Intended for handling private_key_jwt client authentication, self-issued JWT and SAML 2.0 bearer grants, signed request objects, encrypted ID tokens and encrypted UserInfo responses. The downloaded client JWK set is cached by the Connect2id server to ensure quick processing of requests that rely on remote JWKs.

  • Updates handling of the optional max_age OpenID authentication request parameter. If max_age is set to zero (max_age=0) the Connect2id server will prompt the end-user for (re)authentication, even if the end-user has an existing valid session with the Connect2id server. This is equivalent to setting the optional prompt OpenID authentication request parameter to login (prompt=login). See issue #993 with the OpenID Connect working group (https://bitbucket.org/openid/connect/issues/993).

  • Adds experimental support for pairwise subject (end-user) identifiers, based on deterministic AES encryption in SIV mode (see RFC 5297).

  • Adds an extra layer of security to issued session IDs, authorisation codes and identifier-based access tokens by provisioning them with a SHA-256 based Message Authentication Code (MAC) (truncated to 128 bits). The HMAC enables detection of online guessing attacks and may also be used to block certain DoS attacks the utilise the above objects.

  • Switches to new JSON-based marshalling of Connect2id server objects stored in Infinispan.

  • Refines diagnostic messages on a client registration error due to invalid or inconsistent client metadata.

  • Refines logging of invalid client authentication attempts at the token endpoint (issue server/199).

Configuration

  • /WEB-INF/jwkSet.json

    • All JSON Web Keys (JWKs) in the Connect2id server JWK set must have a key identifier ("kid" JWK parameter) and specify the intended key use ("use" JWK parameter).

    • All RSA JWKs intended for signing of objects (ID tokens, UserInfo JWTs and self-contained access tokens) must have their use parameter set to "sig" (signature). Required to prevent mix up with future RSA JWKs intended for encrypting objects to the Connect2id server.

    • Adds support for optional EC JWKs with curves P-256, P-384 and P-521 for signing of ID tokens and UserInfo JWTs. The EC JWKs must have a key identifier ("kid" JWK parameter) and be flagged for specify signature use ("use":"sig").

    • All AES JWKs intended for symmetric encryption of self-contained access tokens must have their use parameter set to "enc" (encryption). Required to prevent mix up with the introduced secret JWKs for HMAC protection and pairwise subject encryption (see below).

    • Adds new secret JSON Web Key (JWK) with ID "hmac" and use "sig" to facilitate HMAC-SHA256 protection of session IDs, authorisation codes and identifier-based access tokens. The HMAC key size must be 256 bits.

    • Adds new symmetric JSON Web Key (JWK) with ID "subject-encrypt" to facilitate AES SIV-mode (RFC 5297) encryption of pairwise subject identifiers. The accepted AES key sizes are 128, 192 and 256 bits.

  • /WEB-INF/oidcProvider.properties

    • Extends the op.idToken.jwsAlgs configuration setting to include support for ID tokens signed with EC DSA (ES256, ES384 and ES512).

    • Adds new op.idToken.jweAlgs configuration setting for the enabled JWE key management algorithms for applying optional additional encryption to issued ID tokens. All standard symmetric and public key JWE algorithms are supported: RSA1_5, RSA-OAEP, RSA-OAEP-256, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW, dir, A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW and A256GCMKW.

    • Adds new op.idToken.jweEncs configuration setting for the enabled JWE content encryption methods for applying optional additional encryption to issued ID tokens. All standard JWE methods are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512, A128GCM, A192GCM and A256GCM.

    • Adds new op.authz.requestJWSAlgs configuration setting for the accepted
      JWS algorithms for signed OpenID authentication requests passed with the optional request_uri or request parameter. The following JWS algorithms are supported: HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 and none.

    • Adds new op.reg.resourceRetriever.httpConnectTimeout configuration setting for the HTTP connect timeout (in milliseconds) when retrieving client resources (JWK sets and request objects specified by URI). Zero implies no timeout. Defaults to 250 ms.

    • Adds new op.reg.resourceRetriever.httpReadTimeout configuration setting for the HTTP read timeout (in milliseconds) when retrieving client resources (JWK sets and request objects specified by URI). Zero implies no timeout. Defaults to 250 ms.

    • Removes the op.reg.preloadCache, op.reg.ldapServer.*, op.reg.ldapUser.*, op.reg.ldapDirectory.*, op.reg.customTrustStore.* and op.reg.customKeyStore.* settings for configuring an LDAP store for the OpenID Connect and OAuth client registration. Configuration of the client registration store is now assumed by the Infinispan.

    • Extends the op.userinfo.jwsAlgs configuration setting to include support for UserInfo JWTs signed with EC DSA (ES256, ES384 and ES512).

    • Adds new op.userinfo.jweAlgs configuration setting for the enabled JWE key management algorithms for applying optional additional encryption to issued UserInfo JWTs. All standard symmetric and public key JWE algorithms are supported: RSA1_5, RSA-OAEP, RSA-OAEP-256, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW, dir, A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW and A256GCMKW.

    • Adds new op.userinfo.jweEncs configuration setting for the enabled JWE content encryption methods for applying optional additional encryption to issued UserInfo JWTs. All standard JWE methods are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512, A128GCM, A192GCM and A256GCM.

  • /WEB-INF/authzStore.properties

    • Removes the authzStore.options.preloadCache, authzStore.ldapServer.*, authzStore.ldapUser.*, authzStore.ldapDirectory.*, authzStore.customTrustStore.* and authzStore.customKeyStore.* settings for configuring an LDAP store for the long-lived (persisted) OpenID Connect and OAuth authorisations. Configuration of the long-lived authorisations store is now assumed by Infinispan.

    • Adds new authzStore.options.discardedAttributes settings to list the optional authorisation attributes that are to be automatically discarded from new authorisation objects, in order to conserve cache memory and backend storage.

    • Adds the "iat" (issued-at) claim to the list of recommended JWT claims to include in self-contained access tokens. Required to facilitate correct inspection of revoked self-contained access tokens.

  • /WEB-INF/infinispan.xml

    • Updates all advanced externalisers for Connect2id server data stored in Infinispan. The externalisers are now declared programmatically, instead of using the Infinispan XML configuration.

    • Adds new "clients.remoteJWKSetCache" cache.

    • Replaces the "op.regCache" cache with "clients.registrationsMap".

    • Replaces the "op.regTokenCache" cache with "op.clientRegTokenMap".

    • Replaces the "authzStore.authzCache" cache with "authzStore.longLivedAuthzMap".

Web API

  • /.well-known/openid-configuration

    • Advertises support for pairwise subject identifiers (subject_types_supported).
  • /clients/

    • Supports registration of OAuth 2.0 and OpenID Connect clients with a JWK set specified by URL (jwks_uri).

    • Supports registration of OpenID Connect clients for pairwise subject identifiers. OpenID Connect clients can be registered for pairwise subject identifiers by setting the "subject_type" parameter to "pairwise"; if more than one redirection URI is specified in the "redirect_uris" parameter, a "sector_identifier_uri" parameter must also be provided.

  • /session-store/rest/v2/sessions

    • Support for the optional "SID" header parameter on POST new session is removed, due to the introduction of HMAC secured session IDs. The key portion of the session ID can be set with the new "SID-Key" header parameter; the Connect2id server will then return the final SID (session key with appended HMAC).
  • /authz-store/rest/v2/revocation

    • Extends the effect of revocation to issued access tokens as well. Previously, revocation was limited to deleting the long-lived authorisations and any associated refresh tokens that match the revocation spec (subject, actor, client_id).
  • /authz-store/rest/v2/inspection

    • Access tokens that fall under the scope of a previous revocation event will be resolved as invalid. Previously, access tokens will appear as valid until they expire, unless the access token is identifier-based and had been explicitly revoked.
  • /monitor/v1/metrics

    • Replaces the "authzStore.numCachedAuthorizations" metric with "authzStore.numLongLivedAuthorizations".

    • Adds new "clientStore.numCachedRemoteJWKSets" metric for the number of cached client JWK sets.

Bug fixes

  • Adds check to prevent client registration of redirect_uris with a fragment component (issue sdk/188).

  • Fixes NPE in the LDAP connector when the asynchronous LDAP result listener receives a notification before the associated timer context is cached (issuer authz-store/117).

  • Fixes Log4j class loading conflict caused by shadowing of Log4j by the Infinispan Embedded package (iss #219).

  • Enables stack trace logging on Infinispan cache manager launch failure.

Dependencies

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

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

  • Upgrades to com.nimbusds:oauth2-oidc-sdk:5.17.1

  • Upgrades to com.nimbusds.nimbus-jose-jwt:4.26.1

  • Upgrades to com.nimbusds:common:2.0

  • Upgrades to Infinispan 8.2.4.Final

  • Upgrades to JAX-RS Jersey 2.23.2

  • Upgrades to com.unboundid:unboundid-ldapsdk:3.2.0

  • Upgrades to Log4j 2.6.2

  • Adds JHades dependency to diagnose class loader issuer at runtime (issue server/219).