General FAQs

Below is a detailed FAQ focusing on the Secure Connectivity Framework and its components, including mTLS, CloudEntity, Thredd CA, and related topics.

Overview

What is the Secure Connectivity Framework?

The Secure Connectivity Framework is a combination of components that enable secure access to Thredd’s resources using a common identity store. These include CloudEntity, Thredd CA, and mTLS termination. It ensures secure communication and access control through features like mTLS, OAuth, and certificate-based authentication.

What is mTLS and how is it used, in the Secure Connectivity Framework?

mTLS (Mutual Transport Layer Security) is a security protocol used to establish trust between clients and servers. In the Secure Connectivity Framework:

  • Transport Certificates issued by Thredd CA are used to establish secure connections.
  • mTLS Termination requires on-premise infrastructure to establish Trust Chains, ensuring that certificates originate from legitimate sources.
  • It is used in the External Host Interface (EHI) setup, and works in the background for the SOAP and REST API setups.

What is the role of CloudEntity in the Secure Connectivity Framework?

CloudEntity is a Software as a Service (SaaS) capability that acts as:

  • Identity Provider (IDP): For Thredd’s interfaces, including Thredd CA and Thredd Portal.
  • OAuth OpenID Provider (OP): For registering and managing customer applications, generating and validating access tokens, and enforcing access control policies.
  • Policy Decision Point (PDP): To allow or deny access to protected Thredd resources based on policies that check attributes like Access Token Claims, mTLS Certificates, and User Roles.

Can I still use or request a VPN setup?

No, VPN setups are not supported. You must connect securely to Thredd using the Secure Connectivity Framework.

Certificates

What is Thredd CA, and what certificates does it provide?

Thredd CA is Thredd’s Certificate Authority responsible for creating and managing certificates. It provides:

  • Transport Certificates: For secure connections between resources.
  • Signing Certificates: For private_key_jwt authentication, signed messages, and non-repudiation.
  • Root and Issuing Certificates: Used to verify Transport Certificates in EHI setups.

What certificates are required for different Thredd applications?

The certificates required for various Thredd applications are as follows:

  • REST API: Requires both Transport and Signing Certificates.
  • SOAP API: Requires only Transport Certificates.
  • External Host Interface (EHI): Requires Root and Issuing Certificates.
  • Thredd Portal: Pre-installed Transport Certificates.
  • Smart Client: Bundled Transport Certificates in the installer.

Single Sign-On

How does SSO work in the Secure Connectivity Framework?

SSO capabilities are provided through CloudEntity, allowing federated authentication. This enables users to authenticate once and gain access to multiple Thredd resources without needing to log in separately for each service. You can also configure your own IdP provider for SSO.

Dynamic Client Registration (DCR)

What is DCR?

DCR is a process supported by CloudEntity for registering client applications dynamically. It simplifies the onboarding of new applications by automating the registration process.

External Host Interface

How do I set up mTLS on EHI?

 

Step 1:Set up Certificates

You need to configure both server and client certificates to enable mTLS.

  1. Set up Server Certificates:
    1. Obtain a Server Certificate from a trusted Certificate Authority (CA) vendor, such as Verizon, Digicert, or Amazon Web Services.
    2. Install the following certificates on your EHI listening endpoint:
      • Server or Leaf Certificate: Issued to individual servers by a CA. This certificate is the "leaf" of the hierarchical tree of trust.
      • Intermediate or Issuing Certificate: Represents the CA that issued the server certificate.
      • Root Certificate: The trusted root of the CA chain.
  1. Set up Client Certificates. Thredd will present its Transport Certificate during the connection handshake. Your system must validate this certificate against the CA chain of trust (Root and Issuing Certificates).

Step 2:Test the mTLS Connection

  1. Test the connection to ensure the mTLS handshake is successful.
  2. Verify that your system can receive and process EHI messages securely.
=

Step 3: Add Optional Security Enhancements

To further secure your mTLS setup, consider implementing the following:

  1. IP Address Allow List:Add Thredd's fixed IP address to your allow list to ensure only authorized traffic is accepted.
  2. Certificate Pinning: Implement certificate pinning to block requests made with incorrect certificates.

Postman Setup

How do I use Postman to test the Secure Connectivity Framework?

Pre-Requisites

  • Install Postman on your system.
  • Create an application in Thredd CA.

 

Main Steps

Step 1: Ensure you have the necessary Transport Certificates (CSR and Private Key) generated and signed by the Thredd Certificate Authority (CA).

Step 2: Add variables from Thredd CA to the variables section in the Postman collection. These include:

  • The Organisation ID (UUID)
  • The Application ID (UUID)
  • The Signing Certificate (KID)
  • The Client ID

Step 3: Add certificates for mTLS:

  1. Open Postman and click on the Settings (gear icon in the top-right corner).
  2. Go to the Certificates tab and click Add Certificate.
  3. For each required host, add the following details:
    • Host: Enter the host URL (e.g., matls-auth.directory.sandbox.threddid.com).
    • CRT file: Upload the PEM file (certificate).
    • KEY file: Upload the private key file.
  4. Repeat this process for all required hosts:
    • matls-auth.directory.sandbox.threddid.com
    • uat-thredd.mtls.eu.authz.cloudentity.io
    • api.uat.threddpay.com
    • api-uat.thredd.com
  5. Save the configuration.

Step 4: Set the following variables in the Variables tab:

  • client_id
  • kid
  • private_key
  • ssa

Step 5: Call initial setup endpoints including the Cloudentity Well-Known and Raidiam Connect Well-Known endpoints.

Step 6: Run DCR through the DCR endpoints. This includes getting the Radium Connect SSA and running DCR itself.

Step 7:Generate an Access Token:

  1. In Postman, expand the Authorisation folder in the API Postman Collection.
  2. Locate the Get Access Token endpoint.
  3. The body of the request should be automatically generated.
  4. Click Send to call the token endpoint.
  5. The access token will be returned in the response and stored in the variables of the Postman Collection.

Step 8:Use the Access Token:

Use the generated access token to authenticate and call other endpoints in the Cards API Postman Collection.

More Information

Where can I find more information?

For more details, refer to the following resources: