8. Identity and Access Integration #
This section defines how Applications must integrate with CLD identity and authorization to ensure unique accountability, least privilege, and strong authentication across all environments.
8.1 Single Sign‑On (SSO) and protocols #
Applications must support Single Sign‑On with CLD’s Identity Provider. The required protocol(s) are PENDING: OIDC/SAML , and the IdP is PENDING: Provider/tenant . Authentication flows must not bypass the IdP (no local username/password stores for human users). Administrative consoles must be IdP‑federated.
8.2 Multi‑Factor Authentication (MFA) and conditional access #
MFA is mandatory for all administrative roles and any access to Restricted data. If conditional access is enforced (e.g., device posture, IP/geo restrictions), Applications must support policy evaluation via the IdP. PENDING: Conditional access rules (device/IP/geo) and enforcement scope
8.3 Provisioning and de‑provisioning #
Account lifecycle must be automated where possible. Preferred model is PENDING: SCIM required: Yes/No . If SCIM is not available, just‑in‑time (JIT) provisioning via SSO is acceptable provided role assignment remains controlled and auditable. De‑provisioning must be immediate upon removal at the IdP; Applications must reconcile and disable stale accounts daily at minimum. Service access tokens/keys tied to departing personnel must be rotated within 24 hours.
8.4 Roles and least privilege #
Applications must implement role‑based (RBAC) or attribute‑based (ABAC) authorization mapped to business functions. Roles must be clearly scoped, documented, and assigned at the IdP or via the Application’s authorization layer, not hard‑coded. CLD standard roles are: PENDING: Admin , PENDING: Operations , PENDING: Read‑only , PENDING: Support (or equivalent). Admin rights are restricted to configuration and security management; Support must default to masked PI and be time‑boxed when elevation is granted. Direct table‑level or superuser access is prohibited in production except via documented break‑glass procedures.
8.5 Service accounts and integrations #
Non‑person identities are allowed only when necessary (e.g., system‑to‑system jobs, APIs). They must be non‑interactive, least‑privilege, and restricted to specific resources and actions. Credentials (client secrets, private keys) must be long, randomly generated, vaulted, and rotated on a defined cadence and upon personnel changes. Mutual TLS (mTLS) or short‑lived tokens are preferred over static credentials. Token TTLs and scope names must follow CLD conventions. PENDING: Token TTLs; scope naming conventions
8.6 Session and token management #
Web sessions must enforce idle timeouts and absolute lifetimes consistent with data sensitivity; re‑authentication is required for privileged actions. OAuth/OIDC tokens must expire quickly, with refresh token usage minimized or disabled where business flows allow. Tokens and session cookies must be transmitted and stored securely (httpOnly, secure, sameSite as appropriate) and never logged. PENDING: Idle timeout (__ minutes) and absolute lifetime (__ hours); access token TTL (__ minutes); refresh token policy
8.7 Third‑party support access #
If vendor support requires access, it must use unique, vendor‑owned identities federated to CLD’s IdP where feasible, enforced with MFA, and granted least‑privilege, time‑boxed access tied to a ticket. Session recording or detailed audit logs must be enabled for elevated support sessions. Shared (“vendor”) accounts are not permitted.
8.8 Access reviews and joiner/mover/leaver (JML) #
Data/System Owners must review user and privileged access at defined intervals (privileged/high‑risk: at least quarterly; other roles: at least semi‑annually). JML events must trigger access changes within defined SLAs (joiner: on start; mover: within 5 business days; leaver: immediate). Applications must expose reports/APIs to support reviews and JML automation.
8.9 Administrative interfaces and exposure #
Administrative interfaces must not be exposed publicly. Access must be restricted to management networks/VPN/zero‑trust entry points and protected by MFA. Default/admin accounts and passwords must be disabled/changed before production use; directory or IdP‑federated administration is preferred over local admin stores.
8.10 Auditability #
Authorization decisions (allow/deny), permission/role changes, account lifecycle events, admin/config changes, and privilege elevations must be logged with who/when/where/what/outcome and a correlation ID. Logs must link identities to actions unambiguously to support investigations and reviews. PENDING: Minimum log fields confirmation; SIEM forwarding requirement and method
8.11 Exceptions #
Any deviation from these requirements (e.g., temporary local auth during integration) requires a documented exception with scope, rationale, compensating controls (e.g., reduced token TTL, additional monitoring), owner, and expiry, approved by the ISO and Executive Sponsor.