ADR-008: Use Janus over Direct PingFederate for Authentication

Context

The xRED ELN Apps layer (External Actions) needs to authenticate Roche users when they are redirected from Signals to an xRED application. The underlying identity infrastructure at Roche is PingFederate backed by Active Directory — this is non-negotiable. The question is how to integrate with it.

The traditional approach is to onboard directly with PingFederate via GIS (Global Information Security). This works but is slow, manual, and inconsistent. Janus was created specifically to wrap PingFederate in a modern, self-service OIDC/OAuth2 layer backed by Amazon Cognito.

Decision

Use Janus as the OIDC/OAuth2 interface to Roche’s PingFederate for all xRED ELN integrations requiring Roche user authentication.

Rationale

Self-service onboarding

This is the primary reason. Direct PingFederate registration requires submitting tickets to GIS, waiting days to weeks for configuration, and dealing with inconsistent support across regions. The Janus team was created specifically to solve this.

With Janus, app registration is GitOps: add a YAML file to the janus/janus repo, submit an MR, and after merge the CI pipeline provisions the Cognito app client automatically. Minutes, not weeks.

Modern OIDC/OAuth2 interface

Janus provides a clean OIDC/OAuth2 interface with standard endpoints (/oauth2/authorize, /oauth2/token, /oauth2/userInfo, /.well-known/openid-configuration). Direct PingFederate integration often involves proprietary configuration, SAML-to-OIDC bridging, and non-standard token formats depending on how the PingFed instance is configured.

SDKs and developer experience

Janus provides official SDKs for Python, Node.js, TypeScript, Angular, Go, R, and Rust, plus Playwright testing SDKs for automated SSO testing in CI. The Python SDK (janus-python) integrates directly with FastAPI — the xRED backend framework.

There is also a Janus CLI (janus login) and an MCP server (@janus/mcp) for LLM-based development workflows.

Direct PingFederate has no equivalent SDK ecosystem for application developers.

AWS IAM integration

Janus provides native AWS STS credential exchange — after OIDC authentication, the id_token can be exchanged for short-lived AWS credentials via the /sts endpoint. Every Roche employee gets a personal IAM Role. This is valuable for integrations that need to interact with AWS services (S3, RDS) using the authenticated user’s identity.

Direct PingFederate does not provide this AWS bridge.

Token richness

The Janus id_token includes Roche-specific claims out of the box:

• preferred_username (unix ID)
• department, cost_center, manager_username
• groups (AD groups, filtered by configurable groupRegex)

This is useful for RBAC — e.g. limiting which users can trigger certain External Actions based on their AD group membership. With direct PingFederate, getting these claims into tokens requires custom configuration per app.

Token exchange (RFC 8693)

Janus supports cross-app token exchange, enabling SSO between xRED integrations without requiring the user to re-authenticate. If an External Action needs to call another xRED service on behalf of the user, the Janus token can be exchanged rather than initiating a new auth flow.

Existing adoption

Other Minerva-hosted applications in the CS CoE / DCC Solutions space already use Janus. The Secure Application Blueprint (Minerva Blueprint) explicitly recommends Janus for user authentication.

Alternatives Considered

Direct PingFederate onboarding

The traditional path. Not chosen because:

• Days to weeks turnaround for app registration via GIS tickets
• Inconsistent support — experience varies by region and team
• No self-service or GitOps model
• No AWS IAM integration
• No SDK ecosystem for application developers
• Custom configuration needed per app for token claims
• The Janus team was created specifically because this approach doesn’t scale

gCS AuthService (Keycloak)

Keycloak is the governance-level standard per the Minerva platform ADRs. It provides OIDC/OAuth2 and SAML with gCustoms for role management. It is a viable alternative but was not chosen because it also requires coordination with the gCS team for app registration (no self-service GitOps), has no AWS IAM bridge, and has a less mature SDK ecosystem for Python/FastAPI.

Keycloak remains relevant if SAML support is ever needed (Janus does not support SAML).

Consequences

• Janus is a dependency outside xRED’s control — app client YAMLs live in the janus/janus repo
• Token refresh requires Janus service availability (30-day refresh token TTL mitigates short outages)
• If Janus is ever deprecated, migration to direct PingFed or Keycloak would be needed. The OIDC/OAuth2 interface is standard, so migration would primarily affect app registration and SDK usage, not the auth flow itself
• SAML is not supported — if an internal system requires SAML federation, a separate integration path would be needed