Blog »

Greater choice of persistence backends with Connect2id server 6.0

2016-06-17

You can now download a preview of the upcoming 6th release of the Connect2id server, our enterprise solution for issuing sign-in and access tokens to apps, whether web-based or mobile.

The highlights at a glance:

Greater choice of persistence backends

The Connect2id server needs to persist two types of data - client registrations and long-lived authorisations. Back in 2012 when we began implementing the OpenID Connect server and targeted the enterprise, we chose LDAP storage for that purpose: it fit well the data model, enterprises knew it, and so did we.

Today, four years on, we're meeting a growing number of customers who have no LDAP experience (because they're start-ups, or have stayed away from traditional enterprise IT for some reason), or wish to utilise a cloud specific solution (such as Amazon's DynamoDB). To help out those customers we rewrote the Connect2id server backend, by migrating to Infinispan's generic data store API, which permits any type of database to be plugged in.

Which persistence backends are going to be supported in version 6.x?

  • File-based -- Data is persisted to a local file on each Connect2id server node. Super easy to maintain (no external database setup required), and offering raw performance that is hard to beat. Our OpenID Connect sign-in benchmark reported 43% greater throughput when we setup a Connect2id server with Infinispan's own Soft-Index File Store, compared against OpenDJ (an LDAP server). On AWS you could use EBS to store the data files. One bit that we still need to resolve with simple file-based storage: support for hot backups.

  • LDAP -- Persisting data to an LDAP directory remains supported. This still has its advantages: the database is external and can be configured for fail-over and multi-master replication; you can run external queries on your client registration and authorisation data with a standard LDAP browser.

  • DynamoDB -- For customers who run their ops in the AWS cloud and wish to have all Connect2id server data stored as JSON objects, with the ability to run external queries on it. DynamoDB support won't make it in time for 6.0, and will appear in a later 6.x release.

  • SQL RDMBS -- In order to support such a wide range of backends, database operations are limited to the most common denominator - loading and storing a value by key (where the value can be treated as an opaque string or binary blob, but may also be stored in some structured form). The database's own indexing and query capabilities are not used; instead of that the Connect2id server now employs an external engine (Apache Lucene). Using an SQL RDMBS, such as MySQL or PostgreSQL, as a simple key-value store is not particularly efficient, unless you want to run external SQL queries on the persisted data, so if we do add support for relational databases, this will happen in later 6.x release.

Pairwise identifiers

Pairwise identifiers promise enhanced privacy by making it harder for OpenID Connect clients to correlate, or "link" user identities. This is achieved by keeping the real user identifier confidential, and providing each registered client with a different
(but consistent) ID for the user.

There are several ways to implement this in a identity provider:

Hashing the user ID, together with the client's sector identifier and some salt is one way. This renders the resulting pairwise ID virtually irreversible.

Another IdP approach is to encrypt the user and sector IDs with a symmetric key. We chose this method (AES/CBC/PKCS5Padding encryption), as it enables the Connect2id server to handle the optional id_token_hint request parameter, and also to support use cases where the ID token is exchanged for an OAuth access token.

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.

Here we must stress that issuing pairwise IDs is not sufficient 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. Email addresses of user fall into this category. But even when all assertions about a user have been considered, correlation may still happen. Cem Paya has a nice discussion on this in his blog post series on pairwise identifiers
(part 1, 2 and 3).

Download

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

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

This will launch a instance of the Connect2id server where data is persisted to a local file store (Infinispan's Soft-Index File Store).

An LDAP directory is still included in the package, but that's only to provide a sample user database.

Important: The Tomcat web server must be launched from the base of the extracted file tree, otherwise the Connect2id server will not be able to find the correct base directory for the file store. We intend to fix this by the time 6.0 gets released.

Questions?

If you have any questions or comments about the new persistence backends, don't hesitate to get in touch with Connect2id support.

Release notes

6.0-pre-1 (2016-06-16)

General

  • Switches to Infinispan's data store APIs for persisting client registry and long-lived authorisation records.

  • Adds support for pairwise subject (end-user) identifiers.

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

  • Refines error messages to clients on invalid and denied client registration requests.

Configuration

  • /WEB-INF/jwkSet.json

    • Adds new symmetric JSON Web Key (JWK) with ID "subject-encrypt" to facilitate AES/CBC/PKCS5Padding encryption of pairwise subject identifiers. The acceptable AES key sizes are 128, 192 and 256 bits.

    • Adds new salt JSON Web Key (JWK) with ID "subject-salt" to facilitate AES/CBC/PKCS5Padding encryption of pairwise subject identifiers. The salt must be at least 128 bits long.

  • /WEB-INF/oidcProvider.properties

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

  • /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 of the optional authorisation attributes that are to be automatically discarded from new authorisation objects, in order to conserve cache memory and back-end storage.

  • /WEB-INF/infinispan.xml

    • Updates all advanced externalisers.

    • Replaces "op.regCache" with "op.clientRegMap".

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

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

Web API

  • /.well-known/openid-configuration

    • Advertises support for pairwise subject identifiers (subject_types_supported).

  • /clients/

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

  • /monitor/

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

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

Dependencies

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

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

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

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

  • Upgrades to com.nimbusds:common:1.102.1

  • Upgrades to org.infinispan:infinispan-embedded:8.2.2.Final

  • Adds new dependency to org.infinispan:infinispan-query:8.2.2.Final

  • Adds new dependency to org.infinispan:infinispan-directory-provider:8.2.2.Final

  • Adds new dependency to org.infinispan:infinispan-persistence-soft-index:8.2.2.Final

  • Adds new dependency to com.nimbusds:infinispan-ldap-cache-store:1.0.2

  • Upgrades to org.apache.logging.log4j:log4j-api:2.6.1

  • Upgrades to org.apache.logging.log4j:log4j-web:2.6.1

  • Upgrades to org.apache.logging.log4j:log4j-slf4j-impl:2.6.1