Connect2id server 8.1

This release of the Connect2id server addresses issues encountered since the release of 8.0 at the start of 2020.

mTLS reverse proxy update

Connect2id server deployments where clients authenticate with a self-signed certificate (self_signed_tls_client_auth) can have the TLS connection terminated at an HTTP proxy. If the client presents an X.509 certificate the proxy passes it to the Connect2id server in a special security HTTP header configured by op.tls.clientX509CertHeader. The certificate is passed encoded as a PEM string, which is essentially the BASE64 encoding of the certificate DER binary with special start and end markers.

Sec-Client-X509-Cert-alaeLuL8geiqu3OhOg1Mafa4Ecu9ahsh: -----BEGIN CERTIFICATE-----MIICsDCCAZigAwIBAgIIdF+Wcca7gzkwDQYJKoZIhvcNAQELBQAwGDEWMBQGA1UEAwwNY2FvajdicjRpcHc2dTAeFw0xNzA4MDcxNDMyMzVaFw0xODA4MDcxNDMyMzZaMBgxFjAUBgNVBAMMDWNhb2o3YnI0aXB3NnUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCdrt40Otrveq46K3BzZuds6wDqsP0kZV+C3GdyTQWl53orBRtPIiEh6BauP17Rr19qadh7t4yFBb5thrXwBewseSNEL4j7sB0YoeNwRsmA29Fjfoe0yeNpLixFadL6dz7ej9xW2suPppIO6jA5SYgL6+S42ZlIauCnSQBKFcdP8QRvgDZBZ4A7CmuloRJst7GQzppa+YWR+Zg3V5reV8Ekrkjxhwgd+rMsGahxijY7Juf2zMgLOXwe68y41SGnn+1RwezAhnJgioGiwY2gP7z2m8yNZXhpUiX+KAP2xvYb60wNYOswuqfpya68rSmYT8mQjld1EPR21dBMjRQ8HfUBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAAIUlqltRlbqiolGETmAUF8AiC008UCUmI+IsnORbHFSaACKW04m1iFH0OlxuAE1ECj1mlTcKb4md6i7n+Fy+fdGXFL73yhlSiBLu7XW5uN1/dAkynA+mXC5BDFijmvkEAgNLKyh40u/U1u75v2SFS+kLyMeqmVxvUHA7qA8VgyHi/FZzXCfEvxK5jye4L8tkAR34x5j5MpPDMfLkwLegUG+ygX+h/f8luKiQAk7eD4C59c/F0PpigvzcMpyg8+SE9loIEuJ9dRaRaTwIzez3QA7PJtrhu9h0TooTtkmF/Zw9HARrO0qXgT8uNtQDcRXZCItt1Qr7cOJyx2IjTFR2rE=-----END CERTIFICATE-----

The PEM encoding is considered safe in HTTP header values (with new lines removed). If the PEM string was left with new lines or other special chars this may break the header, so some proxies, like Nginx, can apply additional URL-encoding on top of the PEM string to prevent this from happening.

Starting with v8.1 the Connect2id server can also accept headers with additional URL-encoding of the PEM certificate.

Sec-Client-X509-Cert-alaeLuL8geiqu3OhOg1Mafa4Ecu9ahsh: -----BEGIN%20CERTIFICATE-----MIICsDCCAZigAwIBAgIIdF%2BWcca7gzkwDQYJKoZIhvcNAQELBQAwGDEWMBQGA1UEAwwNY2FvajdicjRpcHc2dTAeFw0xNzA4MDcxNDMyMzVaFw0xODA4MDcxNDMyMzZaMBgxFjAUBgNVBAMMDWNhb2o3YnI0aXB3NnUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCdrt40Otrveq46K3BzZuds6wDqsP0kZV%2BC3GdyTQWl53orBRtPIiEh6BauP17Rr19qadh7t4yFBb5thrXwBewseSNEL4j7sB0YoeNwRsmA29Fjfoe0yeNpLixFadL6dz7ej9xW2suPppIO6jA5SYgL6%2BS42ZlIauCnSQBKFcdP8QRvgDZBZ4A7CmuloRJst7GQzppa%2BYWR%2BZg3V5reV8Ekrkjxhwgd%2BrMsGahxijY7Juf2zMgLOXwe68y41SGnn%2B1RwezAhnJgioGiwY2gP7z2m8yNZXhpUiX%2BKAP2xvYb60wNYOswuqfpya68rSmYT8mQjld1EPR21dBMjRQ8HfUBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAAIUlqltRlbqiolGETmAUF8AiC008UCUmI%2BIsnORbHFSaACKW04m1iFH0OlxuAE1ECj1mlTcKb4md6i7n%2BFy%2BfdGXFL73yhlSiBLu7XW5uN1%2FdAkynA%2BmXC5BDFijmvkEAgNLKyh40u%2FU1u75v2SFS%2BkLyMeqmVxvUHA7qA8VgyHi%2FFZzXCfEvxK5jye4L8tkAR34x5j5MpPDMfLkwLegUG%2BygX%2Bh%2Ff8luKiQAk7eD4C59c%2FF0PpigvzcMpyg8%2BSE9loIEuJ9dRaRaTwIzez3QA7PJtrhu9h0TooTtkmF%2FZw9HARrO0qXgT8uNtQDcRXZCItt1Qr7cOJyx2IjTFR2rE%3D-----END%20CERTIFICATE-----

Nginx has marked the plain PEM certificate variable ($ssl_client_cert) as deprecated and encourages use of $ssl_client_escaped_cert.

Check out the updated TLS configuration guide for more information.

Seamless rolling upgrades from 7.x when refresh tokens are issued

Connect2id server 8.0 introduced a new encoding of issued refreshed to enable the inclusion of encrypted metadata. Tokens with the old encoding (7.x and earlier) will still be honoured and accepted, so OAuth clients with them can still used them to obtain new access tokens.

However, in a rolling cluster upgrade from Connect2id server 7.x to 8.x if a client tries to use a new refresh token obtained from an 8.x server instance against an 7.x instance the token will not be recognised, resulting in a invalid_grant error.

To prevent such errors from occurring during rolling cluster upgrades Connect2id server 8.1 introduces a new authzStore.options.issueLegacyRefreshTokens configuration property. When enabled the server will issue refresh tokens in the old encoding, so 7.x and older instances in the cluster can recognise them.

After the rolling upgrade is completed and all server instances are 8.1 the setting should be disabled (on a subsequent upgrade) to start issuing refresh tokens with the new encoding.

Other features and resolved issues

Grant handler loading (for the password, client credentials and other grants) was broken in 8.0 which prevented loading of multiple SPI implementations. The behaviour was fixed, so deployments which load two or more grant handlers but enable only one can continue to function as before.

The new release also improves logging and exception reporting in several areas.

For more information read the release notes below.

Download

To download a ZIP package of Connect2id server 8.1:

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

SHA-256: 365de12aca275789d0899ba3a04d0a38b78d479fbe8e50690f7cbb75e5f8ab7e

As WAR package only:

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

SHA-256: 210f4fec34db979bda24b02855c223d3f7751435f9f306678e4d680ab2bd4ace

Questions?

Contact Connect2id support.


Release notes

8.1 (2020-02-03)

Summary

  • Updates mTLS client authentication by accepting client X.509 certificates with additional URL-encoding on top of the PEM encoding when the certificate is received from a TLS termination proxy via the HTTP security header configured by "op.tls.clientX509CertHeader".

  • Adds a new "authzStore.options.issueLegacyRefreshTokens" configuration property to facilitate seamless rolling cluster upgrades from Connect2id server 7.x and earlier versions to 8.x. When this setting is enabled Connect2id server 8.1 instances will issue refresh tokens in the old encoding supported and recognised in 7.x (instead of the new refresh token encoding with additional encryption of metadata, introduced in 8.0). After the rolling upgrade is completed and all instances are 8.1 the setting can be disabled (on a subsequent upgrade) to start issuing new refresh tokens with the new encoding.

Configuration

  • /WEB-INF/oidcProvider.properties

    • Client X.509 certificates received with the HTTP security header configured by "op.tls.clientX509CertHeader" can have an optional additional URL-encoding (also called percent encoding) of the PEM-encoded string. The presence of additional URL-encoding is automatically detected.
  • /WEB-INF/authzStore.properties

    • New "authzStore.options.issueLegacyRefreshTokens" configuration property. If true the Connect2id server will issue refresh tokens in the legacy format supported up to v7.x. Intended to facilitate seamless rolling cluster upgrades to v8.x and later without producing invalid_grant errors when a new 8.x refresh token is used at a Connect2id server 7.x instance. The default value is false (no issue of legacy refresh tokens).

Resolved issues

  • Fixes parse exception reporting when reading DynamoDB items from "pending_codes" and "id_access_tokens", logs JSON with error message (issue authz-store/169).

  • Fixes loading of OAuth 2.0 grant handler SPIs when multiple implementations are available (broken in Connect2id server 8.0, issue server/515).

  • Logs the names of the OAuth 2.0 grant handler SPI classes when multiple are enabled for a given grant type (issue server/515).

  • Logs the names of an SPI class when a single must be loaded and multiple are available (issue common/60).

  • Disables the setting of the "jsessionid" cookie in the Connect2id server banner page (index.jsp) as no cookie or session is required by the page (issue server/516).

Dependency changes

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

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

  • Upgrades to com.nimbusds:common:2.36

  • Adds new dependency to io.github.cemiltokatli.uricomponent:uri-component:1.0

Connect2id server 8.0

The start of 2020 marks eight years since the inception of the Connect2id server and, coincidentally or not, the arrival of its 8th major release. Here are the highlights.

PAR

Pushed Authorisation Requests (PAR) is a new spec from the OAuth WG which matured quickly to useful completeness and its PAR endpoint is now implemented by the Connect2id server.

OAuth 2.0 clients, including OpenID relying parties, can post an authorisation request to the PAR endpoint to obtain a request_uri handle for it, which the client then uses to complete the request at the authorisation endpoint in the usual way.

What are the benefits of submitting the authorisation request parameters directly to the Connect2id server?

  • Frees applications from potential browser limitations on URL size which can matter with complex authorisations. Previously, in order to work around that clients' only option was request JWTs passed by URI (request_uri). PAR makes it possible to "store" the request on the Connect2id server.

  • The authorisation parameters are no longer exposed to the browser, end-user, web server logs, etc.

  • Confidential clients get authenticated up-front and the authorisation request validity is checked before triggering a front-end redirection to the authorisation endpoint for login and consent. If necessary additional checks on the authorisation request can be performed at the PAR endpoint.

Example posting of an authorisation request to the PAR endpoint for a client registered for basic authentication:

POST /par HTTP/1.1
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

response_type=code
&scope=openid%20email
&client_id=fcb5e4f1
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

On success the PAR endpoint returns an opaque URI handle for the request plus an indication when it's going to expire:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "request_uri" : "urn:ietf:params:oauth:request_uri:OsL1Z3VqIxAT9R77wB7KCw.5-cQUNt9DygE4XxnYjysnw",
  "expires_in"  : 60
}

The client completes the authorisation request by passing the request_uri handle to the authorisation endpoint, as if it was a regular request object (JWT) passed by URL - no other parameters are required!

GET /login?request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3A... HTTP/1.1

PAR is simple to use, give it a try!

OpenID Connect eKYC / Identity Assurance

Providers of verified identities, for know-you-customer (KYC) compliance or general identity assurance, should look at the new extension that is being developed at a working group inaugurated in the first days of January at the OpenID Foundation.

The extension defines a JSON schema for requesting verified claims via the standard claims OpenID authentication request parameter and returning them in a specially designated container in UserInfo responses or in ID tokens.

Example UserInfo response with verified claims and metadata explaining the actual verification, based on methods such as ID document (paper or electronic), utility bill or qualified electronic signature (eIDAS):

{
  "sub"             : "478e4589-0145-42e2-a54e-bc291f9c7af3",
  "verified_claims" : {
    "verification" : {
       "trust_framework"      : "eidas_ial_high",
       "time"                 : "2020-01-08T12:12:59+02:00",
       "verification_process" : "6994ca5a-3615-4347-9062-c9037d847d3b",
    },
    "claims"       : {
      "given_name"  : "Alice",
      "family_name" : "Adams",
      "birthdate"   : "1987-12-01"
    }
  }
}

Check out our guide how to configure your Connect2id server for delivering verified claims in this format.

New JWT profiles for access tokens

The default JWT codec for access tokens can now mint them in three different profiles:

  • c2id-1.1 -- Connect2id server specific profile, available since v7.17, with the JWT "typ" (type) header set to "at+jwt". This is the default profile.

  • c2id-1.0 -- Connect2id server specific profile, available since v1.0, outputs identical JWT claims as c2id-1.1 but doesn't set the JWT "typ" (type) header.

  • oauth-1.0 -- Standard profile in development at the OAuth working group.

Set the authzStore.accessToken.codec.jwt.profile configuration property to switch to a profile other than the default c2id-1.1. The standard profile (oauth-1.0) being developed by the OAuth WG is a sensible alternative, but bear in mind that breaking changes to it are possible before it becomes an RFC (we are going to version them though).

Sample JWT for an access token minted in the oauth profile.

Header:

{
  "alg" : "RS256",
  "typ" : "at+jwt",
  "kid" : "CXup"
}

Claims:

{
  "iss"       : "https://c2id.com",
  "sub"       : "alice",
  "aud"       : "https://c2id.com",
  "iat"       : 1579272283,
  "exp"       : 1579272883,
  "jti"       : "BLk7RoQCVKA",
  "client_id" : "000123",
  "scope"     : "openid email",
  "clm"       : [ "!Bg" ],
  "uip"       : { "groups": [ "admin", "audit" ] }
}

Feeding OpenID claims into the access token

Thanks to a clever customer suggestion it is now possible to feed arbitrary consented OpenID claims from a configured claims source into the issued access tokens, for consumption by resource servers / web APIs. To do that simply prefix the claim name with access_token: when submitting consent to the Connect2id server during an authorisation session. This works for all supported OAuth 2.0 grants, not just for authorisation code and implicit.

To feed a patientId claim into the token while letting the rest be delivered by the default method - the UserInfo response:

{
  "scope"  : [ "openid", "email" ],
  "claims" : [ "access_token:patientId", "email", "email_verified" ]
}

If the access token is self-contained (JWT) the patientId claim will be added as a top-level claim with the same name. If the access token is identifier-based the patientId claim will appear as top-level claim in the token introspection response.

Example JWT claims for an access token with patientId:

{
  "iss"       : "https://c2id.com",
  "sub"       : "alice",
  "aud"       : "https://c2id.com",
  "iat"       : 1579272283,
  "exp"       : 1579272883,
  "jti"       : "BLk7RoQCVKA",
  "client_id" : "000123",
  "scope"     : "openid email",
  "clm"       : [ "!Bg" ],
  "uip"       : { "groups": [ "admin", "audit" ] },
  "patientId" : "p041193"
}

Two additional prefixes are supported:

  • access_token:uip: -- Causes the OpenID claim to be merged into the top-level "uip" (optional preset UserInfo claims) JSON object claim.

  • access_token:dat: -- Causes the OpenID claim to be merged into the top-level "dat" (optional data) JSON object claim.

If the claim name clashes with an existing top-level access token claim it will be ignored and not fed into the access token.

Certified OpenID Connect session management and logout profiles

The OpenID Foundation recently piloted a conformance suite for the three OpenID Connect profiles for session management and logout. In December the Connect2id server (v7.18.1) obtained certification for them.

Upgrading to 8.0

Upgrading to Connect2id server 8.0 requires the addition of a new JSON Web Key (JWK) to the server key set and may also require an update to the backend database schema, depending on its type.

New refresh-token-encrypt JWK

Newly issued refresh tokens will have an additional layer of encryption to protect certain token metadata. For that a new AES JWK with kid (key ID) "refresh-token-encrypt" must be present in the server JWK set. You can create one with the updated generator.

To extract the refresh token encryption key from the generated JWK set with help of the jq utility:

cat jwkSet.json | jq '.keys[] | select(.kid=="refresh-token-encrypt")'

Backend database

Identifier-based access tokens will now be persisted in hashed form. The measure is intended to prevent token leakage if the database or a database backup is exposed and the HMAC key of the Connect2id server to attach an authenticity and integrity code to each token identifier is also compromised. Previously the only protection against undetected token identifier leaks from the database or a backup was the HMAC key remaining secret.

To facilitate this and other changes to persisted access tokens the Infinispan data structure for them was updated and so was the database schema, depending on database type.

  • SQL databases -- The Connect2id server will automatically detect if the schema for the "id_access_tokens" table needs updating and will add the required new columns.

  • AWS DynamoDB -- Schema-less, no changes necessary.

  • LDAP -- Manual schema update required, see the release notes for detailed instructions.

  • Redis -- The new access tokens will be simply stored in a different bucket (14) instead of the old one (4) to prevent corruption.

When upgrading to Connect2id server 8.0 if there are existing identifier-based access tokens in the database issued by a older Connect2id server version the authzStore.options.legacyPlainKeysInStorage configuration property can be set to true to enable their successful introspection, otherwise they will be deemed invalid. Note that enabling this configuration imposes imposes additional database reads and a performance penalty during introspection.

Download

To download a ZIP package of Connect2id server 8.0:

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

SHA-256: 0543d751b1a85b8d7bf02c3f58c6008804bd9a96155f31364b9e2603cd0333b1

As WAR package only:

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

SHA-256: d3c85bfbe619b0efa5293a9609eb11a273554497b99f94234e6e66df8e45258c

Questions?

Contact Connect2id support.


Release notes

8.0 (2020-01-01)

Summary

  • Supports OAuth 2.0 Pushed Authorization Requests. See https://tools.ietf.org/html/draft-ietf-oauth-par-00

  • Supports OpenID Connect for Identity Assurance 1.0 (draft 08). See https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html

  • The default self-contained (JWT) access token codec implementing the SelfContainedAccessTokenClaimsCodec SPI now supports multiple JWT profiles:

    • c2id-1.1 -- Connect2id server specific profile, available since v7.17, with the JWT "typ" (type) header set to "at+jwt".

    • c2id-1.0 -- Connect2id server specific profile, available since v1.0, outputs identical JWT claims as c2id-1.1 but doesn't set the JWT "typ" (type) header.

    • oauth-1.0 -- Standard profile in development at the OAuth working group, see draft-ietf-oauth-access-token-jwt-03

    The active JWT profile for access tokens is selected by a new optional "authzStore.accessToken.codec.jwt.profile" configuration property.

  • Consented OpenID claims can now be fed into the access token by prefixing their name with "access_token:". For example, "access_token:email" will cause the "email" claim to be retrieved from the configured OpenID claims source and fed into each access token for the given OAuth 2.0 grant. If the access token is self-contained (JWT) the "email" claim will be added as a top-level claim with the same name. If the access token is identifier-based the "email" claim will appear as top-level claim in the token introspection response.

    Two additional prefixes are supported:

    • "access_token:uip:" -- Causes the OpenID claim to be merged into the top-level "uip" (optional preset UserInfo claims) JSON object claim.

    • "access_token:dat:" -- Causes the OpenID claim to be merged into the top-level "dat" (optional data) JSON object claim.

    If the claim name clashes with an existing top-level access token claim it will be ignored and not fed into the access token.

  • Identifier-based (or key-based) access tokens are now stored in hashed form (SHA-256 truncated to 128 bits) to prevent token leakage if the database or a database backup is exposed and the HMAC SHA-256 key (the Connect2id server JWK with key ID "hmac") to attach an authenticity and integrity code to each token identifier is also compromised. Previously the only protection against undetected token identifier leaks from the database or a backup was the HMAC SHA-256 key remaining secret.

    When upgrading to Connect2id server 8.0 if there are existing identifier-based access tokens in the database issued by a previous Connect2id server version the "authzStore.options.legacyPlainKeysInStorage" configuration property can be set to true to enable their successful introspection, otherwise they will be deemed invalid.

  • Upgrades the Infinispan and backend database schemas for the identifier-based access tokens.

    On startup the Connect2id server will automatically create the new required "id_access_tokens" table columns for a relational MySQL, PostgreSQL and Microsoft SQL Server databases.

    Connect2id server deployments with an LDAP v3 backend database (such as OpenLDAP or OpenDJ) need to update the LDAP schema manually to version 1.10 see https://bitbucket.org/connect2id/server-ldap-schemas/src/1.10/ , the OpenLDAP schema diff https://bitbucket.org/connect2id/server-ldap-schemas/diff/src/main/resources/ oidc-authz-schema-openldap.ldif?at=1.10 &diff1=d9599b598753ec3037b784b29baeac0e28bf7615 &diff2=49115daf531b48c2d9fd0f766721d84c28576eae and the OpenDJ schema diff https://bitbucket.org/connect2id/server-ldap-schemas/diff/src/main/resources/ oidc-authz-schema-opendj.ldif?at=1.10 &diff1=d9599b598753ec3037b784b29baeac0e28bf7615 &diff2=49115daf531b48c2d9fd0f766721d84c28576eae

    Connect2id server deployments with a DynamoDB database are essentially schema-less.

    Connect2id server deployments with Redis as the primary in-memory and caching store use a new bucket (database) with number 14 to store tokens in the new format. Cached tokens in the old format in Redis bucket 4 will remain there until they expire.

  • Introduces a new AES JSON Web Key (JWK) in the Connect2id server JWK set for encrypting and authenticating refresh tokens without the need for a database lookup. The encryption will also enable the inclusion of additional metadata and the implementation of advanced security measures in future Connect2id server versions. Existing refresh tokens without the additional encryption layer will continue to be valid and will be handled transparently.

Configuration

  • /WEB-INF/jwkSet.json

    • Introduces a new AES 256 bit octet sequence JWK with use "enc" (encryption) and ID "refresh-token-encrypt" for encrypting issued refresh tokens. This key is required, starting from Connect2id server 8.0.
  • /WEB-INF/oidcProvider.properties

    • New "op.par.lifetime" configuration property which sets the lifetime of the pushed authorisation requests (PAR), in seconds. Must not be shorter than 10 seconds. The default value is 60 seconds.

    • New "op.authz.includeRawClaimsRequestInPrompt" configuration property which enables / disables inclusion of the raw OpenID "claims" request parameter in the consent prompts of the authorisation session web API, under "claims" -> "raw_request". Access to the raw "claims" request parameter may be required when processing requests for verified claims (OpenID Connect for Identity Assurance 1.0). The default values is false (disabled).

    • New "op.assurance.supportsVerifiedClaims" configuration property which enables / disables advertisement of OpenID Connect for Identity Assurance 1.0 support in OpenID provider metadata and inclusion of the optional transaction specific "purpose" OpenID authentication parameter in the consent prompts of the authorisation session web API. Corresponds to the "verified_claims_supported" OpenID provider metadata parameter. The default values is false (disabled).

    • New "op.assurance.supportedTrustFrameworks" configuration property. Lists the supported trust frameworks if OpenID Connect for Identity Assurance 1.0 support is enabled. Corresponds to the "trust_frameworks_supported" OpenID provider metadata parameter.

    • New "op.assurance.supportedIdentityEvidenceTypes" configuration property. Lists the supported identity evidence types if OpenID Connect for Identity Assurance 1.0 support is enabled. Corresponds to the "evidence_supported" OpenID provider metadata parameter.

    • New "op.assurance.supportedIDDocumentTypes" configuration property. Lists the supported ID document types if OpenID Connect for Identity Assurance 1.0 support is enabled. Corresponds to the "id_documents_supported" OpenID provider metadata parameter.

    • New "op.assurance.supportedIdentityVerificationMethods" configuration property. Lists the supported identity verification methods if OpenID Connect for Identity Assurance 1.0 support is enabled. Corresponds to the "id_documents_verification_methods_supported" OpenID provider metadata parameter.

    • New "op.assurance.supportedVerifiedClaims" configuration property. Lists the supported verified claims if OpenID Connect for Identity Assurance 1.0 support is enabled. Corresponds to the "claims_in_verified_claims_supported" OpenID provider metadata parameter.

  • /WEB-INF/authzStore.properties

    • New "authzStore.accessToken.codec.jwt.profile" configuration property. Sets the JWT profile to use for access tokens minted by the default self-contained access token codec. See the SelfContainedAccessTokenClaimsCodec SPI JavaDoc for more information.

      Supported profiles:

      • c2id-1.1 -- Connect2id server specific profile, available since v7.17, with the JWT "typ" (type) header set to "at+jwt".

      • c2id-1.0 -- Connect2id server specific profile, available since v1.0, outputs identical JWT claims as c2id-1.1 but doesn't set the JWT "typ" (type) header.

      • oauth-1.0 -- Standard profile in development at the OAuth working group, see draft-ietf-oauth-access-token-jwt-03

      The default value is c2id-1.1.

    • New "authzStore.options.legacyPlainKeysInStorage" configuration property. If true the Connect2id server will support retrieval of legacy plain keys for identifier-based access tokens from storage after upgrading to Connect2id server 8.x, false to ignore such keys which will cause the introspection of the linked access tokens to flag them as invalid. Note that enabling this configuration causes additional database reads and a performance penalty during introspection. The default value is false (no support for legacy plain access token keys).

  • /WEB-INF/log4j.xml

    • The root logger level ("INFO") can now be overridden by setting the "log4j.level" Java system property.
  • /WEB-INF/infinispan-*.xml

    • Updates the data structure for the identifier-based access tokens, which is now named "authzStore.idAccessTokenMap".
  • /WEB-INF/infinispan-*-redis-*.xml

    • Deployments using Redis as primary caching and in-memory store will use a new bucket with number 14 for the identifier-based access tokens. Cached tokens in the old format in Redis bucket 4 will remain there until they expire.

Web API

  • /par

    • New endpoint for receiving back-channel OAuth 2.0 authorisation and OpenID authentication requests, also called Pushed Authorization Requests (PAR). Confidential clients must authenticate with the same registered method as for the token endpoint. The complete specification is at https://tools.ietf.org/html/draft-ietf-oauth-par-00
  • /authz-sessions/rest/v3/

    • If op.authz.includeRawClaimsRequestInPrompt=true the raw OpenID "claims" request parameter will be included in the consent prompt API responses (as JSON object member "claims" -> "raw_request").

    • If OpenID Connect for Identity Assurance 1.0 is enabled (op.assurance.supportsVerifiedClaims=true) and the OpenID authentication request includes the transaction specific purpose parameter, the parameter will be included in the consent prompt API responses (as JSON object member purpose).

    • The "claims" parameter of the consent objects enables OpenID claims to be fed into the access token by prefixing their name with "access_token:". For example, "access_token:email" will cause the "email" claim to be retrieved from the configured OpenID claims source and fed into each access token for the given OAuth 2.0 grant. If the access token is self-contained (JWT) the "email" claim will be added as a top-level claim with the same name. If the access token is identifier-based the "email" claim will appear as top-level claim in the token introspection response.

      Two additional prefixes are supported:

      • "access_token:uip:" -- Causes the OpenID claim to be merged into the top-level "uip" (optional preset UserInfo claims) JSON object claim.

      • "access_token:dat:" -- Causes the OpenID claim to be merged into the top-level "dat" (optional data) JSON object claim.

      If the claim name clashes with an existing top-level access token claim it will be ignored and not fed into the access token.

  • /monitor/v1/metrics

    • Adds new meters for the Pushed Authorisation Request (PAR) endpoint:

      • "parEndpoint.successfulRequests" -- Meters successful PAR requests.

      • "parEndpoint.invalidRequests" -- Meters invalid PAR requests.

      • "parEndpoint.invalidClientErrors" -- Meters "invalid_client" errors at the PAR endpoint.

      • "parEndpoint.serverErrors", serverErrors -- Meters server errors (HTTP 500) at the PAR endpoint.

SPI

Upgrades the Connect2id server SDK to com.nimbusds:c2id-server-sdk:4.12

  • com.nimbusds.openid.connect.provider.spi.par.PARValidator

    • New SPI for performing additional validation of received Pushed Authorisation Requests (PAR). See https://www.javadoc.io/doc/com.nimbusds/c2id-server-sdk/4.12/ com/nimbusds/openid/connect/provider/spi/par/PARValidator.html
  • com.nimbusds.openid.connect.provider.spi.tokens

    • The self-contained and identifier-based access token codecs can now be configured via Connect2id server properties which are obtained by calling the TokenCodecContext.getCodecProperties method, for example to enable support of multiple token profiles.

    • The self-contained access token codec interface (SelfContainedAccessTokenClaimsCodec) is extended with new advancedEncode and advancedDecode methods to enable setting and validation of the JWT "typ" (type) header.

    • The AccessTokenAuthorization interface adds support for custom top-level access token claims via the new getOtherTopLevelParameters method.

Resolved issues

  • Fixes the expiration logic for refresh tokens when the Connect2id server is configured with authzStore.refreshToken.alwaysUpdate=true (issue authz-store/166).

  • Fixes "authzStore.accessTokenIssues" metering on successful refresh token usage (issue authz-store/167).

  • Fixes persistence of client_id metadata for cached request_uri claims in multi-tenant Connect2id server deployments (issue server/507).

  • Updates AWS SDK to 1.11.632 to support IAM role for Amazon EKS (issue server/503).

Dependency changes

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

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

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

  • Updates to org.cryptomator:siv-mode:1.2.2

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

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

  • Updates to com.nimbusds:infinispan-cachestore-dynamodb:3.5.2

  • Upgrades to com.nimbusds:infinispan-cachestore-sql:4.1.1

  • Updates to org.postgresql:postgresql:42.2.8

  • Updates to com.unboundid:unboundid-ldapsdk:4.0.14

  • Updates to com.amazonaws:aws-java-sdk-bundle:1.11.632

  • Upgrades to com.nimbusds:c2id-server-ldap-schemas:1.10

  • Updates to Infinispan 9.4.17.Final.

  • Updates to com.nimbusds:jgroups-dynamodb-ping:1.2.3

The Connect2id server obtains OpenID Connect logout certification

Logout confirmation

The OpenID Foundation recently extended its certification suite with tests for the three OpenID Connect specifications for managing sessions and letting a relying party (RP) receive logout notifications:

With the new tests in place we took the opportunity to certify the implemented logout functions of the Connect2id server, which have been in place for several years now.

The test logs were submitted on the 15th of December 2019 and can be viewed on the OpenID certifications page.

We would like to thank Filip Skokan, Roland Hedberg, Mike Jones and the rest of the team at the OpenID Foundation for taking care of the certification program and adding new useful tests over the years.

Logot tests

Deterministic encryption with AES SIV and where it's indispensable

When it comes to symmetric block ciphers, there are several modes of operation. These differ in how the ciphertext that exceed the block size of the cipher is formed. With AES, for example, the block size is 128 bits. Without going into too much detail, it's important to know that you can't simply concatenate the ciphertexts produced by a block cipher without leaking plaintext data.

Most modes of operation rely on a so-called initialization vector or IV, which is a fixed-size byte input that (as opposed to the encryption key) doesn't need to be secret but is required to decrypt a ciphertext. There are different ways to generate such an IV. The most common are simply random IVs. However, randomness means that encrypting the same cleartext twice will result in two different ciphertexts. For many applications this is a desirable property, as an attacker wouldn't be able to determine whether two ciphertexts correspond to the same cleartext. However, for certain scenarios we strictly want a given cleartext to always encrypt to the same ciphertext. In this case we speak of deterministic encryption.

One mode of operation that allows such deterministic encryption is the SIV mode, specified in RFC 5297. SIV stands for synthetic initialization vector and works by deterministically deriving an IV from the input during encryption. The IV is then prepended to the ciphertext. During decryption it can then be used to validate the cleartext and therefore notice whether the ciphertext has been tampered with. This property makes it a so-called authenticated encryption algorithm.

One field of application of this algorithm is deterministic filename encryption, as used in the Cryptomator cloud encryption utility. Since Cryptomator is an open source project which has its encryption code published as separate libraries, other software can easily integrate it. Connect2id employed the AES SIV implementation in the OpenID Connect SDK to generate deterministic encrypted (pairwise) user identifiers, for increasing privacy in single sign-on.

Example user ID encryption with AES SIV:

user ID: alice
encrypted: Osy9fFgs2PRJAk9JE0-4d3kIvxMFOLpoyX_yVZZmkG4r

The open source nature of the Cryptomator AES SIV library allows for security audits to be performed. One was undertaken by Tim McLean on behalf of Connect2id and its finds were published on the project page. All found issues have been successfully resolved in close collaboration with the Cryptomator team.

The Cryptomator AES SIV library for Java can be found on GitHub:

https://github.com/cryptomator/siv-mode

Connect2id server 7.18.1 maintenance release

This is a maintenance release of the Connect2id server which fixes three issues in the code and the configuration. Two of those issues were introduced in v7.18, so you are encouraged to ignore it and update to this release instead.

You can find more information about the fixed issues in the released notes below.

Download

To download a ZIP package of Connect2id server 7.18.1:

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

SHA-256: a871d49f2d27ec4bd913c492948c284553f2b66eade5215cf4a2bd762c7ff91c

As WAR package only:

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

SHA-256: fa844422babde8bf3dd4880eb785bc25550eefef8a7a541feeca5530e7900d31

Questions?

Contact Connect2id support.


Release notes

7.18.1 (2019-11-30)

Resolved issues

  • Fixes a bug introduced in 7.18 on fixing issue oauth-oidc-sdk/277 which caused client GET and PUT registration responses to return HTTP status code 201 instead of 200 on success (issues oauth-oidc-sdk/282, server/501).

  • A relying party initiated logout request with a post-logout redirection URI must produce an error on a missing ID token hint instead of not honouring the requested redirection (issue server/500).

  • Restores the uppercase name of JGROUPSPING table in default-jgroups-jdbc_ping-mysql.xml and default-jgroups-jdbc_ping-postgres95.xml, changed to lowercase in v7.18. Also sets the name to uppercase for the new default-jgroups-jdbc_ping-sqlserver.xml introduced in v7.18 (issue server/502).

  • Updates the default JDBC URL for MySQL databases in /WEB-INF/infinispan-*-mysql.xml and default-jgroups-jdbc_ping-mysql.xml with the more correct mysql database identifier instead of mariadb. This is done to prevent potential issues if client protocol compatibility between MySQL and MariaDB breaks at some point in future. JDBC URLs for MariaDB should use the mariadb identifier. For more information see https://mariadb.com/kb/en/library/about-mariadb-connector-j/#connection-strings (issue server/499).

Dependency changes

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