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 2^nd 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).