Central Identity Broker Architecture

Identity Federation

QueryTek Tapestry acts as a neutral identity broker, federating authentication between enterprise Identity Providers (IdPs) and partner platforms. We normalize identity claims into a canonical model, enabling consistent routing and policy enforcement while maintaining strict multi-tenant isolation.

Identity Brokering Model

Tapestry implements a central identity broker pattern to simplify partner integrations and ensure consistent identity handling across all platform boundaries.

Inbound Federation

Enterprise → Tapestry

  • Accepts SAML 2.0 and OIDC protocols
  • Managed federation via specialized providers
  • Multi-tenant IdP configuration support
  • Protocol normalization at boundary

Canonical Claims

Internal Representation

  • Vendor-neutral identity normalization
  • Minimized attribute surface area
  • Tenant-scoped subject identifiers
  • Role and permission mapping

Outbound Federation

Tapestry → Partner

  • Protocol translation (SAML, OIDC, JWT)
  • Partner-specific claim mapping
  • Short-lived signed tokens
  • Fail-closed routing on identity errors

Supported Protocols

Tapestry supports both major enterprise SSO protocols, with translation capabilities to bridge protocol mismatches:

  • SAML 2.0: Enterprise standard for federated authentication
  • OIDC: Modern OAuth 2.0-based identity layer
  • Protocol Translation: OIDC ↔ SAML bridging
  • JWT Tokens: Lightweight partner authentication

Identity Normalization

All inbound identity is normalized into a canonical claims model at the Identity Service boundary:

  • tenant_id: Multi-tenant isolation scope
  • subject_id: Stable per-tenant user identifier
  • email: Primary contact and audit trail
  • display_name: User-friendly representation
  • roles: Tenant-scoped authorization

Security Properties

Identity handling enforces strict security and privacy controls:

  • Short-lived tokens with expiration enforcement
  • Signed assertions with certificate verification
  • JWKS rotation for OIDC signing keys
  • SAML certificate lifecycle management
  • No cross-tenant credential exposure

Canonical Claims Model

The Canonical Claims Envelope defines the internal identity representation used for routing, policy enforcement, and audit logging throughout Tapestry.

Claim Required Description
tenant_id ✓ Stable identifier for the customer tenant (Tapestry tenant)
subject_id ✓ Stable per-tenant user identifier (canonical subject)
email ✓ Primary user email (normalized to lowercase)
display_name Human-readable name
given_name First name component
family_name Last name component
roles Array of role strings (tenant-scoped)

Identity Federation Flow

Step 1: Enterprise Authentication

User initiates authentication through their enterprise IdP:

  • User accesses launch URL for partner application
  • Tapestry redirects to tenant's configured IdP
  • IdP authenticates user (SAML or OIDC flow)
  • IdP returns signed assertion to Tapestry callback

Step 2: Claims Normalization

Tapestry Identity Service normalizes inbound claims:

  • Validates signature and assertion integrity
  • Extracts identity attributes from IdP response
  • Maps to canonical claims model
  • Applies tenant-specific attribute mappings
  • Creates Tapestry session with normalized identity

Step 3: Partner Routing

Routing Orchestrator evaluates partner launch request:

  • Retrieves partner configuration from registry
  • Validates tenant-partner enablement
  • Applies routing policy and context rules
  • Generates partner-specific identity assertion
  • Redirects user to partner with signed token

Multi-Tenant Isolation

Identity federation enforces strict tenant boundaries to prevent data leakage:

  • Tenant-scoped subject identifiers
  • Isolated IdP configurations per tenant
  • No cross-tenant identity correlation
  • Tenant boundary validation in all APIs

Partner Adapters

Each partner integration uses an adapter pattern for protocol-specific handling:

  • Canonical claims → partner claim mapping
  • Protocol selection (SAML, OIDC, JWT)
  • Partner-specific signing and encryption
  • Context channel metadata injection

Observability

Comprehensive logging and monitoring for identity operations:

  • Authentication success and failure events
  • Protocol translation and claim mapping
  • Partner routing decisions and outcomes
  • Token lifecycle (issuance, refresh, expiration)

Architectural Decisions

Our identity federation architecture reflects deliberate design choices optimized for enterprise interoperability, security, and operational reliability.

Protocol Strategy

  • Multi-protocol federation support
  • Protocol translation capabilities
  • Vendor-neutral implementation
  • Standards-based authentication

Identity Model

  • Centralized claim normalization
  • Minimized attribute surface
  • Tenant isolation enforcement
  • Auditable identity lifecycle

Federation Architecture

  • Managed provider integration
  • Consistent routing semantics
  • Short-lived credential patterns
  • Continuous compliance alignment

Integration Patterns

Enterprise IdP Onboarding

  • SAML metadata exchange
  • OIDC client registration
  • Custom attribute mapping configuration
  • Multi-IdP support per tenant

Partner Integration

  • Protocol capability declaration
  • Claim requirement specification
  • Certificate and key exchange
  • Sandbox testing and certification

Operational Management

  • Certificate rotation automation
  • JWKS key lifecycle management
  • IdP metadata refresh
  • Partner configuration versioning

Identity federation architecture maintained by Engineering and Security teams. Design decisions documented and validated through governance review processes.