Identity & Access Management
Business Value: CCP delivers enterprise-grade, multi-tenant identity and access management as a foundational service — not an add-on. Every tenant gets a dedicated identity domain, every user gets the right level of access and no more, and every action is attributed to an authenticated, authorized identity.
IAM Architecture
CCP IAM is built on two complementary components:
- Keycloak v24.0.5 — The authentication engine: manages user identities, sessions, tokens, MFA, and federation with external identity providers
- OpenFGA — The authorization engine: evaluates fine-grained role-based access control for every resource operation based on relationship tuples
This separation ensures that authentication (who you are) and authorization (what you can do) are independently scalable, auditable, and maintainable.
Per-Tenant Keycloak Realm Isolation
The most critical architectural property of CCP IAM is that every tenant gets a dedicated Keycloak realm — a completely isolated identity domain.
Unlike platforms that implement multi-tenancy as namespace-level separation within a shared identity store, CCP creates a fully independent Keycloak realm per tenant, with:
- Its own user database and password policies
- Its own role definitions and group memberships
- Its own MFA configuration and authentication flows
- Its own identity federation connections (one tenant can federate with ADFS; another with a different IdP)
- Its own session management and token configuration
A user in Tenant A's realm cannot authenticate against Tenant B's realm under any circumstance — there is no shared identity layer that could create cross-tenant leakage.
Role-Based Access Control — 18 Pre-Defined Roles
Authorization is enforced through OpenFGA with 18 pre-defined RBAC roles organized across two levels:
7 Organization-Level Roles
| Role | Scope | Capabilities |
|---|---|---|
| Platform Super Admin | Global (all tenants) | Full platform control — all tenants, infrastructure, configurations, quota management |
| Tenant Admin | Tenant | Full control within tenant — users, cells, quotas, identity settings, service policies |
| Organization Admin | Organization within Tenant | Manage cells, users, and resource policies within their organization |
| Cell Admin | Cell (Project) | Create and manage resources, invite users, and configure access within a specific cell |
| Member | Cell (Project) | Deploy and manage workloads, provision resources — full operational access within the cell |
| Viewer | Cell (Project) | Read-only access to resource status, dashboards, and usage metrics |
| Billing Admin | Tenant | Access metering data, showback reports, and quota management without resource provisioning rights |
11 Service-Specific Roles
Service-specific roles provide granular access to individual service categories, enforcing the principle of least privilege:
| Service Role | Service Domain | Access Scope |
|---|---|---|
| Compute Admin | Compute (VM, CaaS, BMaaS) | Provision, manage, and decommission compute resources |
| Storage Admin | Storage | Manage block, object, file, and archival storage resources |
| Network Admin | Networking | Configure VPCs, load balancers, VPN, firewall, and DNS resources |
| Security Admin | Security Services | Manage WAF, SIEM, CSPM, HSM, and security policy configuration |
| Database Admin | Database Services | Provision and manage DBaaS instances (Oracle, MongoDB, MS SQL, MariaDB) |
| Monitoring Admin | Monitoring | Configure alarms, notification policies, and access operational dashboards |
| Backup Admin | Backup Services | Manage backup policies, schedules, and restoration operations |
| Identity Admin | IAM | Manage users, roles, MFA policies, and federation configuration within the tenant |
| Kubernetes Admin | Container / CaaS | Full Kubernetes cluster management, application deployment, and namespace administration |
| Read-Only Operator | All services | Read access to all resource states and metrics; no provisioning or configuration rights |
| Support Engineer | Operations | Operational access for troubleshooting without privilege to modify resources or access data |
Authentication Mechanisms
OAuth2 / OpenID Connect
All CCP portal and API authentication uses OAuth2/OIDC, implemented through Keycloak:
- JWT Tokens: Short-lived JSON Web Tokens for API authentication
- Token Refresh: Seamless token refresh for long-lived sessions without re-authentication
- PKCE Flow: Proof Key for Code Exchange for secure browser-based authentication
- Service-to-Service: Client credentials flow for microservice-to-microservice authentication
Multi-Factor Authentication
CCP supports multiple MFA methods through Keycloak's MFA engine:
- TOTP (Time-based OTP): Standard authenticator apps (Google Authenticator, Microsoft Authenticator)
- SMS: One-time codes delivered via SMS to the user's registered mobile number
- Email OTP: One-time codes delivered via email
- MFA Policy Enforcement: Administrators can mandate MFA for specific roles (e.g., all Cell Admins must use TOTP)
- Break-Glass Procedures: Documented emergency access procedures for MFA device loss
Identity Federation
SAML 2.0 Federation
CCP supports SAML 2.0 federation with enterprise identity providers, enabling organizations to use their existing corporate identity infrastructure:
| Identity Provider | Integration Method | Use Case |
|---|---|---|
| Microsoft ADFS | SAML 2.0 | Enterprise SSO for organizations using on-premises Windows Active Directory |
| Microsoft Entra (Azure AD) | SAML 2.0 / OIDC | Cloud-based enterprise identity for hybrid organizations |
| BSS Portal (ATB) | SAML 2.0 / API | Customer onboarding and subscription identity from the billing system |
When a user authenticates via a federated IdP, Keycloak maps the external identity to the appropriate CCP tenant realm and role assignment — without storing the user's credentials in CCP.
Session Management
- Session Timeout: Configurable session idle and absolute timeout per tenant
- Admin Force Logout: Platform administrators and tenant admins can force-terminate user sessions immediately (for security incidents or employee departure)
- Concurrent Session Control: Optionally limit the number of concurrent sessions per user
- Session Audit: All session creation, refresh, and termination events logged with timestamp and IP address
Privileged Access Management
CCP includes Privileged Access Management (PAM) as a Foundation Service in MVP1:
- Privileged Session Recording: Administrative sessions to infrastructure are recorded for audit
- Just-in-Time Access: Temporary privilege elevation with automatic expiration
- Approval Workflows: High-privilege operations require approval from a second administrator
- Credential Vaulting: Privileged credentials stored in encrypted vault; checked out per session, never exposed directly
Tenant Isolation — Summary
| Isolation Layer | Mechanism | What It Isolates |
|---|---|---|
| Identity | Dedicated Keycloak realm per tenant | Users, roles, sessions, authentication flows, federation |
| Authorization | OpenFGA with tenant-scoped relationship tuples | All resource operations — no cross-tenant authorization |
| Network | VPC with tenant-isolated routing (VXLAN/EVPN) | All network traffic between tenants |
| Storage | Tenant-scoped storage quotas and access policies | Storage access — no cross-tenant volume or bucket access |
| Compute | OpenStack tenant isolation, Kubernetes namespaces | VM and container resource visibility and access |
| Metering | Scoped metering per tenant/cell/user | Usage data and billing records — no cross-tenant visibility |