Content Comparison

...

CDCM often interacts with various external systems in an infrastructure. For example, a server-side guard JavaScript may call an external system while verifying that a concept may be saved, or CDCMs creates a UI for the selection of a work product reference by accessing the REST API of Storage Location. These calls to external systems may require different forms of authentication. It is not safe to assume that all external systems may be authenticated using the authenticated users bear token obtained from the customer’s identity provider (IDP hereafter); some system may not be directly integrated with the customers IDP or may not support REST calls using the IDP’s bearer token (e.g. IBM ELM). Also for some external systems it may be desirable to authenticate with a Service Principal (aka technical user).

The Connection routing Routing feature configures the authentication calls to all external systems. For each outbound call to an external system CDCM consults the connection-routing.ymlfile to determine how this call should be authenticated.

...

If an outgoing Http request matches https://my.elm.host1/** connection routing will use OAuth 1.0a for authentication with the external server.

Supported

...

Authentication Mechanisms

The supported authentication mechanism are OAuth 2.0, OAuth1.0a, Fixed Headers and Bearer Token Forward. They operate in different ways and require different connections settings in the connection-routing.yml file.

...

This authentication flow uses the bearer token in the Authorization header in the incoming request for the request to the external server. This could e.g. be a JWT or an OAuth2.0 token.

Connections via the Gateway Proxy

Connections to external servers can be established via the Gateway Proxy. Simply provide the Gateway URI and the external URIs, that should be proxied in connection-routing.yml.

If the Proxy itself requires authentication, it can be referenced in the Connections Configuration and the Connection Routing Configuration in the same way that authentication to external servers is configured.

See Example Configuration

See Reference

Configuration

Connection routing is configured using the file connection-routing.yml. This file has to be put in the application’s working directory.

Deployment in Kubernetes

The connection-routing.yml can be placed into a kubernetes secret, and mounted into the CDCM container. The name of this secret is "cdcm-connection-routing", the value of is the connection-routing.yml file.

To integrate the connection-routing.yml file into your CDCM deployment, you need to create a secret called “cdcm-connection-routing” in the namespace of your cdcm deployment.

Example connection-routing.

...

There are two ways to do this:

1. Use kubectl

kubectl create secret generic cdcm-connection-routing --from-file=connection-routing.yml=./connection-routing.yml -n cdcm

2. f the secret has to be created manually or from a vault, use this template:

apiVersion: v1
data:
  connection-routing.yml: <base64 encoded content of the file connection-routing.yml>
kind: Secret
metadata:
  name: cdcm-connection-routing
  namespace: cdcm
type: Opaque

Save the file as connection-routing.yml and apply it with:

kubectl apply -f connection-routing.yml -n <namespace>

Example connection-routing.yml

...

yml

This examples defines various external servers and their required authentication mechanisms and a Gateway Proxy configuration. Connections to the Gateway Proxy in this example are authenticated using OAuth 2.0.

gateway-proxy:
    uri: http://gateway-proxy.host/proxy/stream
    root-uris:
        - https://elmdemo.smartfacts.com:9443/**

connection-routing:
  - cdcm-connection-id: proxy-oauth2
    methods: ALL
    root-uris:
      - http://gateway-proxy.host/proxy/**
  -
    cdcm-connection-id: forward-bearer
    methods: ALL
    root-uris:
      - https://host1/**
      - https://host2/data/**
  -
    cdcm-connection-id: oauth20
    methods: GET,POST
    root-uris:
      - https://host3:4552/v1.0/**

  -
    cdcm-connection-id: oauth10a
    methods: ALL
    root-uris:
      - https://host4/oauth10a/**

  -
    cdcm-connection-id: fixed-headers
    methods: ALL
    root-uris:
      - https://host5:8080/**

connections:
  forward-bearer:
    connection-type: BEARER_TOKEN_FORWARD
  proxy-oauth20:
    connection-type: OAUTH20
    client-id: <client-id>
    client-secret: <client-secret>
    user-info-uri: <user-info-uri>
    scopes: openid, profile, email, Sites.Read.All
    authorization-uri: <authorization-uri>
    token-uri: <token-uri>
  oauth20:
    connection-type: OAUTH20
    client-id: <client-id>
    client-secret: <client-secret>
    user-info-uri: <user-info-uri>
    scopes: openid, profile, email, Sites.Read.All
    authorization-uri: <authorization-uri>
    token-uri: <token-uri>
  oauth10a:
    connection-type: OAUTH10A
    consumer-key: <key>
    consumer-secret: <secret>
    root-services: <root-services-uri>
    service-principal-enabled: false
  fixed-headers:
    connection-type: FIXED_HEADERS
    headers:
      Authorization: <auth-header-value>
      X-Custom-Auth-Header: <custom-auth-header-value>

Save the file with the name connection-routing.yml.

There are two ways to apply this configuration:

1. Using kubectl

kubectl create secret generic cdcm-connection-routing --from-file=connection-routing.yml=./connection-routing.yml -n cdcm

2. If the secret has to be created manually or from a vault, first base64-encode the contents of the file connection-routing.yml and then use this template:

apiVersion: v1
data:
  connection-routing.yml: <base64 encoded content of the file connection-routing.yml>
kind: Secret
metadata:
  name: cdcm-connection-routing
  namespace: cdcm
type: Opaque

Save the file as connection-routing.yml and apply it with:

kubectl apply -f connection-routing.yml -n <namespace>

Reference

Gateway Proxy

Configuration Routing Table

...

• RFC 6749: The OAuth 2.0 Authorization Framework

• OAuth 1.0a Specifications

• RFC 7617: The 'Basic' HTTP Authentication Scheme

• Gateway Proxy