Skip to content

Identity and Access

Keycloak-brokered identity federation for secure, institutional single sign-on.

Overview

RosettaHub uses Keycloak as an identity broker to federate authentication across institutional identity providers. Keycloak does not act as an identity store -- it brokers trust between your institution's identity provider and RosettaHub, enriching tokens with research-environment-specific claims.

Identity Flow

The canonical pattern for a research institution using an external identity provider:

Researcher browser
│
▼
RosettaHub  ──OIDC──►  Keycloak (broker)  ──OIDC/SAML──►  Identity Provider
│                              │                                 (Azure AD, ADFS,
enriches token                 authenticates user                 Shibboleth, etc.)
adds project claims            enforces org MFA policy
enforces step-up if needed     Conditional Access

No researcher credentials touch Keycloak's user database. Keycloak holds only the federation mapping and the claims it adds on top.

Supported Identity Providers

Protocol Providers
SAML 2.0 Azure AD, ADFS, Shibboleth, Okta, PingFederate
OIDC Azure AD, Google Workspace, Keycloak-to-Keycloak
LDAP Active Directory, OpenLDAP
OAuth 2.0 GitHub, Google, institutional OAuth servers

Token Enrichment

When a researcher authenticates, Keycloak enriches the identity token with RosettaHub-specific claims before passing it to the platform:

Claim Description
Platform roles Platform-wide capabilities (rh-default, rh-cloudaccount, etc.)
Federation roles Cloud access perimeter -- regions, services, and instance types
Scope Subscription tier and quotas (rhs-scope-*)
Organization membership Which organizations the user belongs to, and their role in each (CPOC, ADMIN, SU)
Portfolio roles Per-portfolio access (rhp-, rhpsu-, rhpadmin- prefixed)
Compliance policies Cloud Custodian policies and standards applied to the user's accounts
MFA status Whether multi-factor authentication was performed
Data access tier Level of data sensitivity the researcher is cleared for

These claims drive authorization decisions across RosettaHub without requiring the platform to query the identity provider again.

Federated Applications

Keycloak provides OIDC tokens not only to RosettaHub but to all RosettaHub-managed applications. Researchers sign in once and gain access to:

Application Purpose
RosettaHub Cloud orchestration and governance
Gitea Version control and airlock workflows for TRE
Apache Superset Data visualization and dashboards
OpenMetadata Data catalog, discovery, and governance
GrandNode2 Marketplace and service catalog

All applications share the same identity context -- a researcher's project membership and access tier are consistent across all tools.

How It Works

  1. Researcher navigates to RosettaHub and clicks "Sign In"
  2. RosettaHub redirects to Keycloak
  3. Keycloak identifies the researcher's institution and redirects to the institutional IdP (e.g., Azure AD)
  4. Azure AD authenticates the researcher using institutional credentials and MFA
  5. Keycloak receives the SAML/OIDC assertion, enriches it with project and access claims
  6. RosettaHub receives a clean OIDC token and grants access based on the enriched claims

The researcher never creates a separate RosettaHub password. Their institutional identity is the single source of truth.

Role Model

All roles are managed as Keycloak roles and carried in OIDC tokens. RosettaHub uses six categories of roles:

Category Purpose
Platform (rh-default, rh-admin, rh-cloudaccount, etc.) Platform-wide capabilities
Federation (regions, services, instance types) Cloud access perimeter -- where and what a user can deploy
Scope (rhs-scope-{id}) Quotas and subscription tiers
Organization (rh-cpoc-{org}, rh-admin-{org}, rh-su-{org}) Who manages what within each organization
Project (same CPOC/ADMIN/SU levels) Who manages project resources
Portfolio (rhp-portfolio-{id}, rhpsu-*, rhpadmin-*) Per-portfolio access control
Compliance (per-policy and per-standard) Cloud Custodian policies enforced on the user's cloud accounts

A user can belong to multiple unrelated organizations, each with its own role assignment. See The Portal for full details on each role category.