Connecting the Database Gateway

Summary. The WKL Database Gateway is the natural first use of TrustBridge: a supplier's existing business application needs access to a customer's data. The gateway governs which data operations are allowed; TrustBridge supplies it with the partner system's verified identity and protects the connection to it. The TLS adapter is the only way in to the gateway and hands it the organization, service, and purpose of each connection; the gateway authorizes every request against its own rules. The supplier needs neither an account in the customer's network nor database credentials. TrustBridge works without the gateway too; this integration is an option, not a prerequisite.

• Database Gateway – a WKL data service that makes databases reachable over HTTP and OData and authorizes every request against rules per alias.
• Alias – a data source published in the gateway, with its own connection and its own rules.
• Trusted proxy – an upstream service whose forwarded identity the gateway adopts, because the gateway is reachable only through that service.
• Partner identity – the combination of organization, service name, and relationship of a connection, as verified by the TLS adapter.

sequenceDiagram
  participant LA as Supplier application
  participant TL as TLS adapter supplier
  participant TA as TLS adapter customer
  participant GW as Database Gateway
  participant DB as Database
  Note over TL,TA: 1. Relationship agreed, both sides' policies active
  LA->>TL: request to the gateway
  TL->>TA: 2. TLS 1.3 with certificates, additional PQ secret, hybrid group
  TA->>TA: check chain, namespace, revocation status, policy
  TA->>GW: request with partner identity and purpose
  GW->>GW: 3. check the alias rule for this identity
  GW->>DB: 4. execute the permitted operation
  DB-->>GW: result
  GW-->>TA: response, operation logged
  TA-->>TL: response
  TL-->>LA: response

1. Agree on the relationship. Customer and supplier agree on a limited trust relationship. In its direction, the customer admits exactly those of the supplier's services that are meant to reach the gateway, for the purpose of the access, and with the cryptographic requirements it demands.
2. Authenticate mutually and protect the connection. The TLS adapters on both sides open a mutually authenticated TLS 1.3 connection, additionally protected by the key agents' post-quantum secret. The customer's adapter checks chain, namespace, revocation status, and relationship policy, and passes the partner identity to the gateway.
3. Check permissions. The gateway checks the request against the alias rule for this partner identity: which tables and views, which operations, which rows.
4. Execute and record. The permitted operation is executed and recorded in the gateway's log, together with the partner identity. The connection setup is recorded in the TLS adapter's log.

Whether a VPN becomes unnecessary depends on what else it is used for. For data access through the gateway, the supplier needs no access to the rest of the customer's network.

graph TD
  subgraph AG [Customer network]
    TA[TLS adapter<br/>the only way in from outside]
    GW[Database Gateway<br/>rules per alias]
    DB[(Database)]
    KA[Key agent]
  end
  EXT[Partner systems]
  EXT -->|TLS 1.3, adapter port| TA
  KA ==>|external PSK| TA
  TA -->|partner identity, local| GW
  GW --> DB
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef auth fill:#fff4ce,stroke:#8a6d00,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef pq fill:#dff6dd,stroke:#107c10,color:#201f1e
  class TA,DB onl
  class GW auth
  class EXT par
  class KA pq
  style AG fill:#ffffff,stroke:#8a8886,color:#201f1e

The step-by-step setup is in Connect a supplier to Database Gateway.

The supplier's application talks to its local TLS adapter as if the gateway were on the same host or in its own network. That holds for in-house applications over HTTP and OData as well as for Microsoft Access, Excel, or Power BI through the WKL OData ODBC Driver or the gateway client. The application needs neither certificates nor keys; TrustBridge manages both on the host.

• The gateway's rules. How rules, aliases, and sign-in methods work is described in the Database Gateway documentation.
• Protection of the legs inside a network. The connection between TLS adapter and gateway, and between gateway and database, is protected by the operator according to its own rules.
• An obligation to use the gateway. TrustBridge protects connections to other applications just as well; the gateway is one integration among several.
• Any claim that a VPN becomes unnecessary in every environment.