ADR-002: Dual Authentication Model for External Data vs External Actions

Context

Signals ELN provides two fundamentally different integration mechanisms with different authentication capabilities:

• External Data (Lists, Tables, Chemical Sources) — server-to-server calls where Signals sends a single Basic Auth header plus an optional client certificate. No browser involved.
• External Actions — the user’s browser redirects to an external application. The browser is involved, enabling richer auth flows.

The integration layer must authenticate both types of traffic while working within these constraints.

Decision

The integration layer implements two distinct authentication models:

External Data path (Lookups)

• Signals sends Basic Auth credentials and a client certificate
• MuleSoft validates the client certificate and IP whitelist
• Gravitee validates the Authorization: Basic header (MuleSoft proxy credentials)
• The Lookups service trusts traffic that has passed both gateways
• Internal system credentials are managed by the Lookups service itself (via Vault secrets)

External Actions path (Apps)

• The user’s browser is redirected to the Apps layer
• Apps performs a dual OAuth handshake:
  1. Roche identity — OAuth via Janus (PingFederate) to authenticate the user’s corporate identity
  2. Signals access token — OAuth with Signals to obtain a token for write-back API calls
• Both tokens are stored in ElastiCache (see ADR-003) for the session duration
• The Roche token is used as a Bearer token for calls to internal systems
• The Signals token is used for write-back calls through MuleSoft

Rationale

The two authentication models are a direct consequence of the Signals platform’s capabilities. External Data provides only a single header — there is no way to pass OAuth tokens or custom credentials. External Actions involve a browser redirect, which opens up standard OAuth flows.

Rather than fighting these constraints, the architecture embraces them and implements the appropriate auth model for each path.

Alternatives Considered

Unified OAuth for both paths

Rejected. External Data integrations do not involve a browser and only support a single Authorization header with Basic Auth. OAuth is not possible for this path.

API key-only authentication for External Actions

Rejected. External Actions involve user-specific operations (viewing their experiments, writing back to their records). User identity is required for access control and audit trails. API keys cannot provide per-user identity.

Consequences

• Two distinct authentication flows must be implemented and maintained
• The Lookups path relies on infrastructure-level security (client cert, IP whitelist, API key) rather than user-level identity
• The Apps path provides full user identity but requires managing OAuth token lifecycle
• Session management complexity for the Apps path (see ADR-003)
• Credential rotation for the Lookups path is managed via Vault and does not require Signals reconfiguration (only the Basic Auth credentials and client cert need to match)