Connect2id server 7.7

Posted on 2018-10-15

We have another update of the Connect2id server for you, which is recommended if you have a deployment with an AWS DynamoDB backend, or intend to use the new feature introduced in version 7.6 for steering implicitly consented OpenID claims into the ID token, instead of returning them at the standard location for all code-based flows, the UserInfo endpoint.

For more information check the release notes below.

Download

To download a ZIP package of Connect2id server 7.7:

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

SHA-256: e6b2e33de5b6701eb5224f8ad203e6917306a90825bdeb19df06b9d724f3956d

As WAR package only:

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

SHA-256: 813fe50a7bf927539d25db527b7312c6fd36a868b3c4e6119c680a495ac93381

Questions?

Get in touch with Connect2id support.


Release notes

7.7 (2018-10-02)

Summary

  • Recommended update for Connect2id server deployments utilising a DynamoDB backend. Sanitises DynamoDB items before a database write to prevent DynamoDB ValidationExceptions when the optional data in client registrations, authorisation objects and other persisted objects contains empty strings or sets. Also adds new a configuration option for creating the DynamoDB tables with selected omitted global secondary indices (GSI) to conserve read and write capacity.

  • Recommended update for Connect2id server deployments utilising the "id_token:" prefix introduced in v7.6 to steer selected implicitly consented OpenID claims for delivery with the ID token instead of the UserInfo endpoint. Fixes a bug which included the prefix in persisted consent.

Configuration

  • /WEB-INF/infinispan-*-dynamodb.xml

    • The global secondary indices (GSI) for the subject (sub), actor (act) and / or client ID (cid) attributes in persisted authorisation (consent) records can be selectively turned off by overriding the default "sub, act, cid" setting with a "dynamodb.authzStore.longLivedAuthzMap.indexedAttributes" Java system property. For example, "sub, act" will cause the creation of GSIs for the subjects and actors only, for client IDs related queries the Connect2id server will fall back to a DynamoDB scan request with a filter expression.

Resolved issues

  • Sanitises DynamoDB items before writing them to the table. Empty strings, empty binary data and empty sets, including those in nested JSON objects (maps), are automatically removed to fit the DynamoDB data model and prevent ValidationExceptions (issue authz-store/154).

  • OAuth 2.0 authorisation requests and OpenID authentication requests with an unsupported PKCE method (RFC 7636) are rejected with an "invalid_request" error and descriptive message, as required in section 4.4.1 of RFC 7636. Previously the Connect2id server would return an HTTP 500 status at the token endpoint if the PKCE method is not supported (other than "plain" and "S256") (issue server/401).

  • Implicitly consented claims with an "id_token:" prefix to trigger release via the ID token instead of at the UserInfo endpoint must be saved without the prefix in persisted authorisation records ("cls") (issue server/399).

Dependency changes

  • Updates to com.nimbusds:infinispan-cachestore-common:2.1

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

Connect2id server 7.6 enhances implicit consent for OpenID claims

Posted on 2018-09-08

September commences with a new release of the Connect2id server for enterprise OpenID Connect and OAuth 2.0, with useful updates in consent, global DynamoDB support and the SAML 2.0 grant handler.

Returning implicitly consented OpenID tokens in the ID token

The Connect2id server supports implicit consent, which means the Identity Provider (IdP) can supply the relying party (RP) with OpenID claims (attributes) about the end-user which were not explicitly asked for in the authentication request.

When implicit consent for an OpenID claim is given, the claim will get delivered according to the response_type parameter of the OpenID authentication request, which for all response types other than response_type=id_token makes the claim available at the UserInfo endpoint, together with any other consented claims, in exchange for the access token that is going to be issued.

To enable implicitly consented OpenID claims to be steered into the ID token instead, we made a small update to the authorisation session web API. Simply prefix the claim name with id_token: and this will make it appear in the ID token instead of at the UserInfo endpoint.

Here is an example The OpenID request with scope openid and email, which means the RP is requesting an ID token for the end-user as well as access to their email and email_verified claims:

https://c2id.com/login?
 response_type=code
 &scope=openid%20email
 &client_id=123
 &state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

The RP has initiated a code flow (response_type=code), so the default delivery method for any consented claims will be the UserInfo endpoint. If the IdP decides to additionally release the name claim, that claim will also appear in the UserInfo. To steer the name claim into the ID token, prefix it with id_token: when submitting the consent to the Connect2id server:

{
  "scope"  : [ "openid", "email" ],
  "claims" : [ "email", "email_verified", "id_token:name" ]
}

You can also make the name claim appear in both ID token and UserInfo:

{
  "scope"  : [ "openid", "email" ],
  "claims" : [ "email", "email_verified", "name", "id_token:name" ]
}

Global DynamoDB tables

If you intend to deploy the Connect2id server in the AWS cloud and persist its data to global DynamoDB tables, for seamless distributed operation across two or more AWS regions, the server can now automatically initialise the tables with the needed streams.

Check out our new guide for setting up the Connect2id server with global DynamoDB tables.

Updated SAML 2.0 grant handler

The SAML 2.0 assertion grant handler was updated from OpenSAML 2.x, which reached its end of life in 2016, to OpenSAML 3.x.

If you implemented a handler for exchanging SAML 2.0 assertions for OAuth 2.0 access tokens, update your code to OpenSAML 3.2 or later. The package names in OpenSAML 3.0 have changed, also the APIs of a few classes, but other than that your your overall handler design and code should not be affected.

The OpenSAML 3 guide by Stefan Rasmusson can help you.

Download

To download a ZIP package of Connect2id server 7.6:

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

SHA-256: e6b2e33de5b6701eb5224f8ad203e6917306a90825bdeb19df06b9d724f3956d

As WAR package only:

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

SHA-256: 813fe50a7bf927539d25db527b7312c6fd36a868b3c4e6119c680a495ac93381

Questions?

Get in touch with Connect2id support.


Release notes

7.6 (2018-09-08)

Summary

  • Updates the authorisation session web API to enable implicitly consented (not requested) OpenID claims to be delivered in the ID token instead of at the UserInfo endpoint (for response types other than id_token).

  • Connect2id server deployments with an AWS DynamoDB backend database can now create the required tables with enabled streaming for replicating table data between two or more AWS regions.

  • Updates the SAML 2.0 grant handler SPIs to OpenSAML 3.x (breaking change).

Configuration

  • /WEB-INF/infinispan-*-dynamodb.xml

    • Adds an optional boolean "enable-stream" configuration XML attribute to create the DynamoDB table with an enabled stream of view type NEW_AND_OLD_IMAGES. Streaming is required to setup the Connect2id server with global DynamoDB tables with replicas in two or more AWS regions. The setting is also exposed via the Java system property "dynamodb.enableStream" (defaults to "false", set to "true" to enable).

Web API

  • /authz-sessions/rest/v3/

    • Updates handling of consent in the authorisation session API. Implicitly consented OpenID claims (not requested by the relying party) can be marked for delivery in the ID token instead of at the UserInfo endpoint by prefixing their name with "id_token:" in the submitted consent to the Connect2id server. For example "id_token:email" will cause an implicitly consented "email" claim to be fed into the ID token. An implicitly consented claim can be delivered by both methods by including it twice, with the "id_token:" prefix an without, for example "id_token:email" and "email". Normally, all implicitly consented OpenID claims are delivered at the UserInfo endpoint, save for when the relying party requests only an ID token to be issued (with response_type=id_token).

SPI

  • com.nimbusds.openid.connect.provider.spi.grants.SelfIssuedSAML2GrantHandler

    • Updates the SAML 2.0 grant handler from OpenSAML 2.x to OpenSAML 3.x. Due to breaking changes in the OpenSAML 3.x API handler existing implementations need to be updated.
  • com.nimbusds.openid.connect.provider.spi.grants.ThirdPartySAML2GrantHandler

    • Updates the SAML 2.0 grant handler from OpenSAML 2.x to OpenSAML 3.x. Due to breaking changes in the OpenSAML 3.x API handler existing implementations need to be updated.

Dependency changes

  • Updates to com.nimbusds:c2id-server-sdk:4.0

  • Updates to com.nimbusds:oauth2-oidc-sdk:6.0

  • Updates to com.nimbusds:nimbus-jose-jwt:6.0.2

  • Updates to OpenSAML 3.2 (breaking change)

  • Updates to com.zaxxer:HikariCP:3.2.0

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

How to create a global DynamoDB table in AWS

Posted on 2018-09-05

In November 2017 AWS announced a DynamoDB feature enabling transparent asynchronous replication of table data between any number of regions. This can be useful in a distributed application and for failover between AWS regions. Data can be written and read in each of the regions with replicas of the table.

This is the missing guide for creating global tables with the AWS Java SDK. You'll need a recent version of the SDK as older releases lack the classes for dealing with global DynamoDB tables.

The steps for creating a global DynamoDB table:

  1. Create a DynamoDB client for each of the AWS regions where you need to have replicas.

  2. In each region create the desired DynamoDB table, with the usual parameters, but also enable the table for streaming and specify what is to be streamed - both the new and old images of the item (StreamViewType.NEW_AND_OLD_IMAGES).

  3. Finally, run a request to turn all those created tables into a single global one, by putting them into a replication group. This request can run in any AWS region.

Here is a Java example:

import java.util.Collection;
import java.util.LinkedList;

import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDB;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClientBuilder;
import com.amazonaws.services.dynamodbv2.model.*;
import org.junit.Test;

public class AWSGlobalTableTest {

    private static final String EU_CENTRAL_1 = "eu-central-1";

    private static final String US_EAST_1 = "us-east-1";

    private static final String TABLE_NAME = "my_global_table";

    @Test
    public void createGlobalTable() {

        // Create a client for each of the regions with table replicas
        AmazonDynamoDB client1 = AmazonDynamoDBClientBuilder
            .standard()
            .withCredentials(DefaultAWSCredentialsProviderChain.getInstance())
            .withRegion(EU_CENTRAL_1)
            .build();

        AmazonDynamoDB client2 = AmazonDynamoDBClientBuilder
            .standard()
            .withCredentials(DefaultAWSCredentialsProviderChain.getInstance())
            .withRegion(US_EAST_1)
            .build();

        // The table spec, must be enabled for streaming
        Collection<KeySchemaElement> keyAttrs = new LinkedList<>();
        keyAttrs.add(new KeySchemaElement("id", KeyType.HASH));

        Collection<AttributeDefinition> attrs = new LinkedList<>();
        attrs.add(new AttributeDefinition("id", ScalarAttributeType.S));

        CreateTableRequest createTableRequest = new CreateTableRequest()
            .withTableName(TABLE_NAME)
            .withKeySchema(keyAttrs)
            .withAttributeDefinitions(attrs)
            .withStreamSpecification(
                new StreamSpecification()
                    .withStreamEnabled(true)
                    .withStreamViewType(StreamViewType.NEW_AND_OLD_IMAGES))
            .withProvisionedThroughput(new ProvisionedThroughput(1L, 1L));

        // Create the table in each region
        client1.createTable(createTableRequest);
        client2.createTable(createTableRequest);

        // The global table request can be executed in any of the regions
        CreateGlobalTableResult createGlobalTableResult = client1.createGlobalTable(
            new CreateGlobalTableRequest()
                .withGlobalTableName(TABLE_NAME)
                .withReplicationGroup(
                    new Replica().withRegionName(EU_CENTRAL_1),
                    new Replica().withRegionName(US_EAST_1)));
    }
}

Global tables will be automatically provisioned with three extra attributes - the timestamp of the item update, in which region that happened and a flag whether the item is pending deletion.

The Connect2id server for IdP, SSO and API security is going to support global DynamoDB tables in the next 7.6 release. This will make it possible to run a global IdP operation, with the ability to service clients and applications close to their deployment location for minimal latency.