generated from coulomb/repo-seed
2303 lines
49 KiB
Markdown
Executable File
2303 lines
49 KiB
Markdown
Executable File
# InfoTechCanon Access Control Model
|
|
|
|
**Short Name:** `ITC-ACCESS`
|
|
**Document Status:** Seed Standard Release Candidate 1
|
|
**Version:** RC1-seed
|
|
**Date:** 2026-05-22
|
|
**Repository Context:** `info-tech-canon`
|
|
**Document Type:** InfoTechCanon Domain Standard
|
|
**Intended Audience:** Security architects, platform engineers, identity engineers, authorization-system designers, service owners, DevSecOps teams, governance designers, application developers, operators, agentic tooling designers, repository maintainers, and standards authors.
|
|
|
|
---
|
|
|
|
# 1. Purpose
|
|
|
|
The **InfoTechCanon Access Control Model** defines a canonical seed model for representing authorization and access-control semantics across applications, platforms, services, infrastructure, repositories, operational tools, data systems, and human-agent environments.
|
|
|
|
It provides the canonical vocabulary for:
|
|
|
|
- subjects,
|
|
- principals,
|
|
- identities as references,
|
|
- resources,
|
|
- actions,
|
|
- permissions,
|
|
- privileges,
|
|
- entitlements,
|
|
- grants,
|
|
- bindings,
|
|
- policies,
|
|
- conditions,
|
|
- authorization requests,
|
|
- authorization decisions,
|
|
- enforcement,
|
|
- sessions,
|
|
- delegation,
|
|
- temporary access,
|
|
- break-glass access,
|
|
- access reviews,
|
|
- and access evidence.
|
|
|
|
This standard deliberately distinguishes access control from generic organization modeling, governance, identity provisioning, and authentication protocols.
|
|
|
|
It answers the core question:
|
|
|
|
```text
|
|
Which authenticated subject may perform which action on which resource,
|
|
under which policy, in which context, with which evidence and review path?
|
|
```
|
|
|
|
---
|
|
|
|
# 2. Position in InfoTechCanon
|
|
|
|
The Access Control Model is a **domain standard** within InfoTechCanon.
|
|
|
|
It depends on the existing seed standards as follows:
|
|
|
|
```text
|
|
Organization = actors, persons, agents, teams, roles, memberships, authority.
|
|
Governance = policies, controls, decisions, exceptions, reviews, evidence.
|
|
Landscape = systems, services, resources, endpoints, repositories, data, runtime objects.
|
|
Task = work items, requests, changes, reviews, remediation.
|
|
Tagging = classification and selectors, not access semantics by default.
|
|
Access = authorization relationships and decisions.
|
|
```
|
|
|
|
```text
|
|
InfoTechCanon
|
|
├── InfoTechCanonCore
|
|
├── InfoTechCanonLandscapeModel
|
|
├── InfoTechCanonOrganizationModel
|
|
├── InfoTechCanonGovernanceModel
|
|
├── InfoTechCanonTaskModel
|
|
├── InfoTechCanonTaggingStandard
|
|
├── InfoTechCanonAccessControlModel <-- this standard
|
|
├── InfoTechCanonSecurityModel
|
|
├── InfoTechCanonDataModel
|
|
├── InfoTechCanonDevSecOpsModel
|
|
├── InfoTechCanonPatternLanguage
|
|
└── Application Profiles
|
|
```
|
|
|
|
---
|
|
|
|
# 3. Boundary with Adjacent Standards
|
|
|
|
## 3.1 Boundary with Organization
|
|
|
|
The Organization Model owns:
|
|
|
|
```text
|
|
Person
|
|
Agent
|
|
Team
|
|
Organization
|
|
Role
|
|
Membership
|
|
Assignment
|
|
Authority
|
|
Responsibility
|
|
Accountability
|
|
Ownership
|
|
Stewardship
|
|
```
|
|
|
|
The Access Control Model owns:
|
|
|
|
```text
|
|
Subject
|
|
Principal
|
|
AccessRole
|
|
Permission
|
|
Privilege
|
|
Entitlement
|
|
Grant
|
|
RoleBinding
|
|
PolicyBinding
|
|
AuthorizationRequest
|
|
AuthorizationDecision
|
|
EnforcementPoint
|
|
AccessSession
|
|
AccessReview
|
|
AccessExceptionReference
|
|
```
|
|
|
|
Boundary rule:
|
|
|
|
```text
|
|
Organization defines who actors are and what organizational roles or responsibilities they carry.
|
|
Access Control defines what authenticated subjects may do to protected resources.
|
|
```
|
|
|
|
## 3.2 Boundary with Governance
|
|
|
|
The Governance Model owns:
|
|
|
|
```text
|
|
Policy
|
|
Control
|
|
ControlObjective
|
|
Decision
|
|
Approval
|
|
Exception
|
|
Risk
|
|
Evidence
|
|
Review
|
|
Audit
|
|
ComplianceRequirement
|
|
```
|
|
|
|
The Access Control Model uses governance concepts for:
|
|
|
|
```text
|
|
access policy references
|
|
access-control objectives
|
|
access reviews
|
|
access exceptions
|
|
access evidence
|
|
access approvals
|
|
risk-based access decisions
|
|
```
|
|
|
|
Boundary rule:
|
|
|
|
```text
|
|
Governance defines why and under what rule access should be controlled.
|
|
Access Control defines how authorization is represented, decided, granted, enforced, and reviewed.
|
|
```
|
|
|
|
## 3.3 Boundary with Landscape
|
|
|
|
The Landscape Model owns:
|
|
|
|
```text
|
|
Service
|
|
ApplicationService
|
|
Repository
|
|
RuntimeResource
|
|
Endpoint
|
|
DataStore
|
|
Dataset
|
|
Environment
|
|
NetworkResource
|
|
PlatformResource
|
|
```
|
|
|
|
The Access Control Model refers to these as protected resources.
|
|
|
|
Boundary rule:
|
|
|
|
```text
|
|
Landscape owns resource identity and relationships.
|
|
Access Control owns access semantics for those resources.
|
|
```
|
|
|
|
## 3.4 Boundary with Security
|
|
|
|
The Security Model should own:
|
|
|
|
```text
|
|
Threat
|
|
Vulnerability
|
|
AttackPath
|
|
SecurityFinding
|
|
SecurityEvent
|
|
SecurityIncident
|
|
SecurityControlImplementation
|
|
```
|
|
|
|
Access Control owns authorization semantics.
|
|
|
|
Security may analyze or test access control as a security domain.
|
|
|
|
## 3.5 Boundary with Identity and Authentication
|
|
|
|
Identity provisioning and authentication are related but distinct.
|
|
|
|
This standard references but does not fully own:
|
|
|
|
```text
|
|
User provisioning
|
|
Identity provider configuration
|
|
Authentication factors
|
|
MFA token lifecycle
|
|
Password policy
|
|
Federation protocol details
|
|
SCIM provisioning protocol
|
|
OIDC authentication protocol
|
|
SAML assertion protocol
|
|
```
|
|
|
|
Access Control begins after or alongside identity proofing and authentication:
|
|
|
|
```text
|
|
Authentication asks: Is this subject who or what it claims to be?
|
|
Authorization asks: What may this subject do now?
|
|
```
|
|
|
|
---
|
|
|
|
# 4. Research Basis and External Alignment
|
|
|
|
This seed standard draws on multiple access-control bodies of knowledge.
|
|
|
|
## 4.1 RBAC
|
|
|
|
Role-Based Access Control provides the classic model of users, roles, permissions, operations, and objects. The NIST/INCITS RBAC reference model distinguishes core RBAC, role hierarchies, and separation-of-duty constraints.
|
|
|
|
## 4.2 ABAC
|
|
|
|
Attribute-Based Access Control models authorization decisions as evaluations of subject, object/resource, action, and environment attributes against policies, rules, and relationships.
|
|
|
|
## 4.3 ReBAC and Zanzibar-Style Authorization
|
|
|
|
Relationship-Based Access Control represents access through relationships among users, groups, resources, tenants, and objects. Zanzibar-style systems use tuples and namespace/configuration models to evaluate authorization at large scale.
|
|
|
|
## 4.4 Policy-Based Access Control
|
|
|
|
Policy-based systems such as XACML, OPA/Rego, Cedar, Keycloak Authorization Services, and similar tools decouple authorization logic from application code and evaluate access requests against explicit policies.
|
|
|
|
## 4.5 OAuth 2.0 and OpenID Connect
|
|
|
|
OAuth 2.0 is an authorization framework enabling limited access to HTTP services, commonly through access tokens. OpenID Connect adds an identity layer on top of OAuth 2.0 for verifying end-user identity and retrieving profile claims.
|
|
|
|
These are protocol and token ecosystems, not complete canonical authorization semantics.
|
|
|
|
## 4.6 SCIM
|
|
|
|
SCIM provides platform-neutral schemas and protocols for provisioning users, groups, and related identity resources across domains.
|
|
|
|
SCIM is a mapping target for identity references, subjects, users, and groups, but does not replace access-control semantics.
|
|
|
|
## 4.7 Kubernetes RBAC
|
|
|
|
Kubernetes RBAC demonstrates practical resource/action authorization using Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. It is a key profile target for platform and cluster access.
|
|
|
|
## 4.8 Keycloak, privacyIDEA, OPA, OpenFGA, Cedar, Casbin
|
|
|
|
Practical tooling demonstrates complementary access-control approaches:
|
|
|
|
```text
|
|
Keycloak
|
|
identity, federation, realm/client roles, authorization services, policy enforcement.
|
|
|
|
privacyIDEA
|
|
MFA and authentication-token orchestration with policy-driven behavior.
|
|
|
|
OPA
|
|
general-purpose policy decision engine and Rego language.
|
|
|
|
OpenFGA
|
|
Zanzibar-inspired fine-grained relationship-based authorization.
|
|
|
|
Cedar / Amazon Verified Permissions
|
|
schema-aware fine-grained authorization policy language and decision service.
|
|
|
|
Casbin
|
|
authorization library supporting many models such as ACL, RBAC, ABAC, ReBAC, PBAC, and others.
|
|
```
|
|
|
|
InfoTechCanon should map to these, not be captured by any one of them.
|
|
|
|
---
|
|
|
|
# 5. Seed Standard Design Stance
|
|
|
|
This standard is a **seed standard**, not a full implementation specification.
|
|
|
|
It shall:
|
|
|
|
1. define canonical access-control semantics,
|
|
2. distinguish identity, authentication, authorization, and governance,
|
|
3. support RBAC, ABAC, ReBAC, ACL, PBAC, and hybrid approaches,
|
|
4. support human and non-human subjects,
|
|
5. support agentic access and operational access,
|
|
6. support fine-grained resource/action authorization,
|
|
7. support temporary, delegated, emergency, and service-account access,
|
|
8. support policy decision and enforcement architecture,
|
|
9. support mappings to real standards and tools,
|
|
10. remain markdown-first and agent-retrievable,
|
|
11. and support future assimilation of access-control standards, products, and implementation patterns.
|
|
|
|
---
|
|
|
|
# 6. Scope
|
|
|
|
## 6.1 In Scope
|
|
|
|
This standard covers canonical representation of:
|
|
|
|
- subjects,
|
|
- principals,
|
|
- identity references,
|
|
- authenticated subjects,
|
|
- resources,
|
|
- protected resources,
|
|
- resource scopes,
|
|
- actions,
|
|
- operations,
|
|
- permissions,
|
|
- privileges,
|
|
- entitlements,
|
|
- grants,
|
|
- role bindings,
|
|
- policy bindings,
|
|
- access policies as references,
|
|
- access-control policies as access-specific artifacts,
|
|
- conditions,
|
|
- attributes,
|
|
- relationships,
|
|
- authorization requests,
|
|
- authorization decisions,
|
|
- authorization evidence,
|
|
- policy enforcement points,
|
|
- policy decision points,
|
|
- policy administration points,
|
|
- policy information points,
|
|
- access sessions,
|
|
- delegated access,
|
|
- temporary access,
|
|
- emergency access,
|
|
- break-glass access,
|
|
- service-account access,
|
|
- agent access,
|
|
- access reviews,
|
|
- access exceptions,
|
|
- and least privilege analysis.
|
|
|
|
## 6.2 Out of Scope
|
|
|
|
This standard does not fully define:
|
|
|
|
- identity proofing,
|
|
- account lifecycle management,
|
|
- password policy,
|
|
- MFA token enrollment,
|
|
- authentication protocol implementation,
|
|
- OAuth flow implementation,
|
|
- OIDC claim design,
|
|
- SAML profile implementation,
|
|
- full SCIM provisioning implementation,
|
|
- HR master data,
|
|
- all cybersecurity incident handling,
|
|
- full IAM product configuration,
|
|
- or legal/compliance interpretation.
|
|
|
|
Those may be mapped, assimilated, profiled, or handled by adjacent standards.
|
|
|
|
---
|
|
|
|
# 7. Normative Language
|
|
|
|
The following terms are used normatively:
|
|
|
|
- **SHALL** indicates a mandatory rule for conformance.
|
|
- **SHOULD** indicates a recommended practice.
|
|
- **MAY** indicates an optional capability.
|
|
- **MUST NOT** indicates a prohibited practice.
|
|
- **SEED** marks a concept defined provisionally here but open to later refinement.
|
|
- **EXTRACT** marks a concept that may later move to a more specialized standard.
|
|
|
|
---
|
|
|
|
# 8. Core Principles
|
|
|
|
## 8.1 Authentication Is Not Authorization
|
|
|
|
The model SHALL distinguish authentication from authorization.
|
|
|
|
Authentication verifies or establishes subject identity.
|
|
Authorization determines whether an authenticated or otherwise recognized subject may perform an action on a resource.
|
|
|
|
## 8.2 Organizational Role Is Not Access Role
|
|
|
|
An organizational role does not automatically imply an access role.
|
|
|
|
Access roles are permission-bearing constructs.
|
|
|
|
## 8.3 Permission Is Not Assignment
|
|
|
|
A permission defines allowed action on resource type or scope.
|
|
An assignment or binding connects a subject, role, permission, or policy to a concrete access scope.
|
|
|
|
## 8.4 Grant Is Not Decision
|
|
|
|
A grant is a durable or time-bound authorization relationship.
|
|
A decision is the result of evaluating a specific access request.
|
|
|
|
## 8.5 Access Requires Scope
|
|
|
|
Access rights SHOULD be scoped to resource, tenant, environment, service, dataset, system, or operational context.
|
|
|
|
## 8.6 Conditions Matter
|
|
|
|
Access may depend on attributes, relationships, time, network, device, authentication strength, risk, purpose, or environment context.
|
|
|
|
## 8.7 Enforcement Is First-Class
|
|
|
|
An access decision has practical effect only if enforced by an enforcement point.
|
|
|
|
## 8.8 Access Must Be Reviewable
|
|
|
|
Access grants, privileged access, emergency access, and agent access SHOULD be reviewable and evidence-carrying.
|
|
|
|
## 8.9 Least Privilege Is a Directional Principle
|
|
|
|
Access-control implementations SHOULD minimize permissions relative to required purpose and scope.
|
|
|
|
## 8.10 Tags Are Not Entitlements by Default
|
|
|
|
Tags may help select resources or policies but MUST NOT become entitlements unless an access-control profile explicitly defines that behavior.
|
|
|
|
---
|
|
|
|
# 9. Canonical Seed Metadata
|
|
|
|
Every access-control artifact SHOULD support structured metadata.
|
|
|
|
Recommended front matter:
|
|
|
|
```yaml
|
|
---
|
|
id: itc-access:Permission
|
|
type: concept
|
|
standard: InfoTechCanonAccessControlModel
|
|
standard_version: RC1-seed
|
|
status: candidate
|
|
canonical_owner: InfoTechCanonAccessControlModel
|
|
preferred_label: Permission
|
|
related:
|
|
- itc-access:Action
|
|
- itc-access:Resource
|
|
- itc-access:Grant
|
|
- itc-access:AuthorizationDecision
|
|
mappings:
|
|
- itc-map:permission-to-rbac-permission
|
|
---
|
|
```
|
|
|
|
Recommended artifact statuses:
|
|
|
|
```text
|
|
idea
|
|
draft
|
|
candidate
|
|
release-candidate
|
|
adopted
|
|
stable
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
Recommended concept statuses:
|
|
|
|
```text
|
|
proposed
|
|
experimental
|
|
candidate
|
|
canonical
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
---
|
|
|
|
# 10. Root Access-Control Taxonomy
|
|
|
|
```text
|
|
AccessControlEntity
|
|
├── SubjectEntity
|
|
│ ├── Subject
|
|
│ ├── Principal
|
|
│ ├── AuthenticatedSubject
|
|
│ ├── HumanSubject
|
|
│ ├── ServiceSubject
|
|
│ ├── AgentSubject
|
|
│ ├── GroupSubject
|
|
│ └── FederatedSubject
|
|
├── ResourceEntity
|
|
│ ├── Resource
|
|
│ ├── ProtectedResource
|
|
│ ├── ResourceType
|
|
│ ├── ResourceInstance
|
|
│ ├── ResourceScope
|
|
│ └── ResourceOwnerReference
|
|
├── ActionEntity
|
|
│ ├── Action
|
|
│ ├── Operation
|
|
│ ├── ResourceAction
|
|
│ ├── AdministrativeAction
|
|
│ ├── PrivilegedAction
|
|
│ └── DelegableAction
|
|
├── AuthorizationEntity
|
|
│ ├── Permission
|
|
│ ├── Privilege
|
|
│ ├── Entitlement
|
|
│ ├── Grant
|
|
│ ├── Denial
|
|
│ ├── AccessRole
|
|
│ ├── RoleBinding
|
|
│ ├── PolicyBinding
|
|
│ └── ScopeBinding
|
|
├── PolicyEvaluationEntity
|
|
│ ├── AuthorizationRequest
|
|
│ ├── AuthorizationDecision
|
|
│ ├── DecisionReason
|
|
│ ├── Condition
|
|
│ ├── Attribute
|
|
│ ├── RelationshipTuple
|
|
│ └── EvaluationContext
|
|
├── EnforcementEntity
|
|
│ ├── PolicyEnforcementPoint
|
|
│ ├── PolicyDecisionPoint
|
|
│ ├── PolicyAdministrationPoint
|
|
│ ├── PolicyInformationPoint
|
|
│ ├── PolicyRetrievalPoint
|
|
│ └── EnforcementResult
|
|
├── SessionEntity
|
|
│ ├── AccessSession
|
|
│ ├── TokenReference
|
|
│ ├── CredentialReference
|
|
│ ├── AuthenticationStrengthReference
|
|
│ └── SessionContext
|
|
├── SpecialAccessEntity
|
|
│ ├── DelegatedAccess
|
|
│ ├── TemporaryAccess
|
|
│ ├── JustInTimeAccess
|
|
│ ├── BreakGlassAccess
|
|
│ ├── ServiceAccountAccess
|
|
│ └── AgentAccess
|
|
└── ReviewEntity
|
|
├── AccessReview
|
|
├── AccessCertification
|
|
├── AccessFinding
|
|
├── ExcessAccess
|
|
├── OrphanedAccess
|
|
├── StaleAccess
|
|
└── AccessRemediation
|
|
```
|
|
|
|
---
|
|
|
|
# 11. Core Concepts
|
|
|
|
## 11.1 AccessControlEntity
|
|
|
|
An **AccessControlEntity** is any identifiable concept used to represent authorization, permissions, access grants, decisions, enforcement, or review.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
id:
|
|
entity_type:
|
|
canonical_name:
|
|
display_name:
|
|
lifecycle_state:
|
|
source_system:
|
|
created_at:
|
|
updated_at:
|
|
```
|
|
|
|
Optional attributes:
|
|
|
|
```yaml
|
|
owner:
|
|
steward:
|
|
governance_scope:
|
|
resource_scope:
|
|
source_confidence:
|
|
valid_from:
|
|
valid_to:
|
|
tags:
|
|
external_references:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.2 Subject
|
|
|
|
A **Subject** is an entity requesting, holding, or exercising access.
|
|
|
|
A subject may be:
|
|
|
|
```text
|
|
human user
|
|
service account
|
|
workload identity
|
|
AI agent
|
|
automation bot
|
|
group
|
|
federated identity
|
|
external partner
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
Subject is the access-control view of an actor.
|
|
Actor semantics are owned by the Organization Model.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.3 Principal
|
|
|
|
A **Principal** is an identity-bearing subject recognized by an access-control system.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
user account
|
|
service account
|
|
federated identity
|
|
client application
|
|
machine identity
|
|
agent identity
|
|
```
|
|
|
|
A principal may map to a Person, Agent, Team, or external identity.
|
|
|
|
---
|
|
|
|
## 11.4 IdentityReference
|
|
|
|
An **IdentityReference** points to an identity record in an identity provider, directory, federation source, SCIM system, IAM system, or local user store.
|
|
|
|
The Access Control Model references identities but does not own identity lifecycle.
|
|
|
|
---
|
|
|
|
## 11.5 AuthenticatedSubject
|
|
|
|
An **AuthenticatedSubject** is a subject whose identity or credential has been verified with a defined authentication strength or context.
|
|
|
|
---
|
|
|
|
## 11.6 Resource
|
|
|
|
A **Resource** is an entity that may be accessed, modified, invoked, viewed, administered, or otherwise acted upon.
|
|
|
|
Resources may include:
|
|
|
|
```text
|
|
service
|
|
API endpoint
|
|
repository
|
|
branch
|
|
environment
|
|
cluster
|
|
namespace
|
|
database
|
|
dataset
|
|
document
|
|
file
|
|
secret
|
|
certificate
|
|
pipeline
|
|
artifact
|
|
dashboard
|
|
tenant
|
|
organization
|
|
configuration
|
|
```
|
|
|
|
Resource identity is usually owned by Landscape or another domain model.
|
|
|
|
---
|
|
|
|
## 11.7 ProtectedResource
|
|
|
|
A **ProtectedResource** is a resource subject to access-control enforcement.
|
|
|
|
---
|
|
|
|
## 11.8 ResourceScope
|
|
|
|
A **ResourceScope** defines the boundary within which access applies.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
tenant
|
|
organization
|
|
project
|
|
repository
|
|
branch
|
|
service
|
|
environment
|
|
namespace
|
|
cluster
|
|
dataset
|
|
record
|
|
region
|
|
```
|
|
|
|
---
|
|
|
|
## 11.9 Action
|
|
|
|
An **Action** is something a subject may attempt to do to a resource.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
read
|
|
list
|
|
create
|
|
update
|
|
delete
|
|
execute
|
|
approve
|
|
deploy
|
|
administer
|
|
impersonate
|
|
assume-role
|
|
download
|
|
share
|
|
grant-access
|
|
```
|
|
|
|
---
|
|
|
|
## 11.10 Operation
|
|
|
|
An **Operation** is a system-specific or API-specific action.
|
|
|
|
Operation may be mapped to canonical Action.
|
|
|
|
---
|
|
|
|
## 11.11 ResourceAction
|
|
|
|
A **ResourceAction** is a canonical action applied to a resource type or resource instance.
|
|
|
|
Example:
|
|
|
|
```text
|
|
repository:write
|
|
environment:deploy
|
|
dataset:read
|
|
secret:rotate
|
|
cluster:admin
|
|
```
|
|
|
|
---
|
|
|
|
## 11.12 Permission
|
|
|
|
A **Permission** is an authorization unit describing an allowed action or set of actions on a resource type, resource instance, or scope.
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
Permission SHOULD separate action, resource, and scope when possible.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.13 Privilege
|
|
|
|
A **Privilege** is a permission or permission set with elevated consequence, sensitivity, or administrative power.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
root shell
|
|
cluster-admin
|
|
user-management admin
|
|
secret-read
|
|
production deploy
|
|
impersonation
|
|
policy edit
|
|
```
|
|
|
|
---
|
|
|
|
## 11.14 Entitlement
|
|
|
|
An **Entitlement** is a permission, access package, role, grant, or benefit assigned to a subject.
|
|
|
|
Entitlement is often used in IAM governance and access review contexts.
|
|
|
|
---
|
|
|
|
## 11.15 AccessRole
|
|
|
|
An **AccessRole** is a permission-bearing role in an access-control system.
|
|
|
|
It is distinct from an organizational role.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
repository-maintainer
|
|
cluster-admin
|
|
billing-reader
|
|
support-agent
|
|
release-manager
|
|
secret-rotator
|
|
```
|
|
|
|
---
|
|
|
|
## 11.16 Grant
|
|
|
|
A **Grant** is a durable or time-bound relationship giving a subject access under defined scope and conditions.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
subject:
|
|
permission_or_role:
|
|
resource_scope:
|
|
conditions:
|
|
granted_by:
|
|
valid_from:
|
|
valid_to:
|
|
source_system:
|
|
evidence:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.17 Denial
|
|
|
|
A **Denial** is an explicit rule, decision, or binding that prevents access.
|
|
|
|
Denials may override grants depending on policy profile.
|
|
|
|
---
|
|
|
|
## 11.18 RoleBinding
|
|
|
|
A **RoleBinding** assigns an AccessRole to a Subject within a ResourceScope.
|
|
|
|
Example:
|
|
|
|
```text
|
|
Subject alice@example.com has AccessRole repository-maintainer on repository info-tech-canon.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.19 PolicyBinding
|
|
|
|
A **PolicyBinding** connects a policy, policy set, or access rule to a subject, resource, tenant, environment, or scope.
|
|
|
|
---
|
|
|
|
## 11.20 AuthorizationRequest
|
|
|
|
An **AuthorizationRequest** is a request to determine whether a subject may perform an action on a resource in a context.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
subject:
|
|
action:
|
|
resource:
|
|
context:
|
|
requested_at:
|
|
request_source:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.21 AuthorizationDecision
|
|
|
|
An **AuthorizationDecision** is the result of evaluating an authorization request.
|
|
|
|
Recommended decision values:
|
|
|
|
```text
|
|
permit
|
|
deny
|
|
not_applicable
|
|
indeterminate
|
|
conditional_permit
|
|
```
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
request:
|
|
decision:
|
|
reason:
|
|
policy_references:
|
|
evaluated_at:
|
|
decision_point:
|
|
evidence:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.22 DecisionReason
|
|
|
|
A **DecisionReason** explains why an authorization decision was reached.
|
|
|
|
Reason may reference:
|
|
|
|
```text
|
|
matched policy
|
|
missing permission
|
|
expired grant
|
|
failed condition
|
|
explicit denial
|
|
insufficient authentication strength
|
|
risk signal
|
|
break-glass requirement
|
|
```
|
|
|
|
---
|
|
|
|
## 11.23 Condition
|
|
|
|
A **Condition** is a requirement that must hold for access to be permitted.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
time window
|
|
network location
|
|
device posture
|
|
MFA present
|
|
ticket reference present
|
|
risk score below threshold
|
|
resource owner approval
|
|
environment is non-production
|
|
```
|
|
|
|
---
|
|
|
|
## 11.24 Attribute
|
|
|
|
An **Attribute** is a property of subject, resource, action, or environment used in policy evaluation.
|
|
|
|
Attribute categories:
|
|
|
|
```text
|
|
subject attribute
|
|
resource attribute
|
|
action attribute
|
|
environment attribute
|
|
session attribute
|
|
risk attribute
|
|
relationship attribute
|
|
```
|
|
|
|
---
|
|
|
|
## 11.25 RelationshipTuple
|
|
|
|
A **RelationshipTuple** represents a relationship used for authorization.
|
|
|
|
Generic form:
|
|
|
|
```text
|
|
subject relation object
|
|
```
|
|
|
|
Examples:
|
|
|
|
```text
|
|
alice viewer document:123
|
|
team-platform maintainer repository:abc
|
|
group-admins admin tenant:customer1
|
|
```
|
|
|
|
This concept supports ReBAC and Zanzibar-style models.
|
|
|
|
---
|
|
|
|
## 11.26 EvaluationContext
|
|
|
|
An **EvaluationContext** is the set of attributes, relationships, session data, resource data, environmental data, and policy references used to evaluate an authorization request.
|
|
|
|
---
|
|
|
|
## 11.27 PolicyEnforcementPoint
|
|
|
|
A **PolicyEnforcementPoint** is the system component that intercepts or controls access and enforces authorization decisions.
|
|
|
|
---
|
|
|
|
## 11.28 PolicyDecisionPoint
|
|
|
|
A **PolicyDecisionPoint** is the system component that evaluates authorization requests and returns decisions.
|
|
|
|
---
|
|
|
|
## 11.29 PolicyAdministrationPoint
|
|
|
|
A **PolicyAdministrationPoint** is the system component or process where access policies are created, maintained, approved, or published.
|
|
|
|
---
|
|
|
|
## 11.30 PolicyInformationPoint
|
|
|
|
A **PolicyInformationPoint** is a source of attributes, relationships, or context used during policy evaluation.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
directory
|
|
HR system
|
|
SCIM service
|
|
CMDB
|
|
resource inventory
|
|
risk engine
|
|
device posture service
|
|
ticket system
|
|
```
|
|
|
|
---
|
|
|
|
## 11.31 PolicyRetrievalPoint
|
|
|
|
A **PolicyRetrievalPoint** stores or retrieves policies for evaluation.
|
|
|
|
---
|
|
|
|
## 11.32 AccessSession
|
|
|
|
An **AccessSession** is a time-bounded context in which a subject exercises access.
|
|
|
|
A session may reference:
|
|
|
|
```text
|
|
token
|
|
credential
|
|
authentication strength
|
|
device
|
|
network
|
|
client
|
|
risk context
|
|
start time
|
|
expiry
|
|
```
|
|
|
|
---
|
|
|
|
## 11.33 TokenReference
|
|
|
|
A **TokenReference** points to a token used in an access session or protocol exchange.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
OAuth access token
|
|
OIDC ID token
|
|
SAML assertion
|
|
Kubernetes service account token
|
|
SSH certificate
|
|
```
|
|
|
|
---
|
|
|
|
## 11.34 CredentialReference
|
|
|
|
A **CredentialReference** points to a credential used for authentication or access.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
password
|
|
SSH key
|
|
API key
|
|
certificate
|
|
MFA token
|
|
hardware key
|
|
workload identity credential
|
|
```
|
|
|
|
---
|
|
|
|
## 11.35 AuthenticationStrengthReference
|
|
|
|
An **AuthenticationStrengthReference** records the strength or assurance of authentication used.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
password-only
|
|
MFA
|
|
phishing-resistant MFA
|
|
hardware-backed key
|
|
workload identity
|
|
mutual TLS
|
|
```
|
|
|
|
---
|
|
|
|
## 11.36 DelegatedAccess
|
|
|
|
**DelegatedAccess** is access where one subject grants or delegates access authority to another subject within defined limits.
|
|
|
|
---
|
|
|
|
## 11.37 TemporaryAccess
|
|
|
|
**TemporaryAccess** is access granted for a limited time.
|
|
|
|
---
|
|
|
|
## 11.38 JustInTimeAccess
|
|
|
|
**JustInTimeAccess** is temporary access granted only when needed, often after approval, ticket reference, risk check, or workflow.
|
|
|
|
---
|
|
|
|
## 11.39 BreakGlassAccess
|
|
|
|
**BreakGlassAccess** is emergency access used when normal processes are insufficient or unavailable.
|
|
|
|
Break-glass access SHOULD be:
|
|
|
|
```text
|
|
rare
|
|
time-bound
|
|
strongly authenticated
|
|
logged
|
|
reviewed
|
|
evidence-carrying
|
|
subject to post-use review
|
|
```
|
|
|
|
---
|
|
|
|
## 11.40 ServiceAccountAccess
|
|
|
|
**ServiceAccountAccess** is access exercised by a service account, machine identity, workload identity, automation, or non-human subject.
|
|
|
|
---
|
|
|
|
## 11.41 AgentAccess
|
|
|
|
**AgentAccess** is access exercised by an AI or software agent.
|
|
|
|
Agent access SHOULD declare:
|
|
|
|
```text
|
|
supervising actor
|
|
scope
|
|
tools
|
|
permissions
|
|
safety boundaries
|
|
audit expectations
|
|
revocation mechanism
|
|
```
|
|
|
|
---
|
|
|
|
## 11.42 AccessReview
|
|
|
|
An **AccessReview** is a governance review of whether access grants, roles, entitlements, privileges, or policies remain appropriate.
|
|
|
|
---
|
|
|
|
## 11.43 AccessCertification
|
|
|
|
**AccessCertification** is a formal attestation that reviewed access remains appropriate or has been corrected.
|
|
|
|
---
|
|
|
|
## 11.44 AccessFinding
|
|
|
|
An **AccessFinding** is a finding produced by access review, audit, analysis, monitoring, or security assessment.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
excess access
|
|
stale access
|
|
orphaned account
|
|
unused privilege
|
|
privilege escalation path
|
|
missing owner
|
|
break-glass misuse
|
|
```
|
|
|
|
---
|
|
|
|
## 11.45 ExcessAccess
|
|
|
|
**ExcessAccess** is access beyond what is needed for the subject's current purpose, role, task, or scope.
|
|
|
|
---
|
|
|
|
## 11.46 OrphanedAccess
|
|
|
|
**OrphanedAccess** is access assigned to a subject, account, or identity reference that no longer has a valid owner, actor, employment/membership relation, or purpose.
|
|
|
|
---
|
|
|
|
## 11.47 StaleAccess
|
|
|
|
**StaleAccess** is access that was once justified but has not been used, reviewed, or renewed within expected limits.
|
|
|
|
---
|
|
|
|
## 11.48 AccessRemediation
|
|
|
|
**AccessRemediation** is work to correct inappropriate, excessive, stale, orphaned, or risky access.
|
|
|
|
AccessRemediation may create Task Model work items.
|
|
|
|
---
|
|
|
|
# 12. Core Relationship Vocabulary
|
|
|
|
Recommended root relationship types:
|
|
|
|
```text
|
|
requests_access_to
|
|
has_permission
|
|
has_privilege
|
|
has_entitlement
|
|
granted_to
|
|
denied_to
|
|
bound_to
|
|
assigned_role
|
|
applies_to_resource
|
|
applies_to_scope
|
|
permits_action
|
|
denies_action
|
|
requires_condition
|
|
evaluated_by
|
|
enforced_by
|
|
provided_by
|
|
retrieved_from
|
|
informed_by
|
|
delegated_to
|
|
expires_at
|
|
reviewed_by
|
|
certified_by
|
|
violates_policy
|
|
remediated_by
|
|
maps_to
|
|
```
|
|
|
|
Relationship records SHOULD support:
|
|
|
|
```yaml
|
|
id:
|
|
relationship_type:
|
|
source_entity:
|
|
target_entity:
|
|
scope:
|
|
valid_from:
|
|
valid_to:
|
|
source_system:
|
|
confidence:
|
|
evidence:
|
|
rationale:
|
|
```
|
|
|
|
---
|
|
|
|
# 13. Access Decision Model
|
|
|
|
## 13.1 Authorization Request Shape
|
|
|
|
A canonical authorization request SHOULD include:
|
|
|
|
```yaml
|
|
subject:
|
|
action:
|
|
resource:
|
|
context:
|
|
time:
|
|
environment:
|
|
session:
|
|
authentication_strength:
|
|
network:
|
|
device:
|
|
risk:
|
|
purpose:
|
|
request_source:
|
|
```
|
|
|
|
## 13.2 Authorization Decision Values
|
|
|
|
Recommended decision values:
|
|
|
|
```text
|
|
permit
|
|
deny
|
|
not_applicable
|
|
indeterminate
|
|
conditional_permit
|
|
```
|
|
|
|
## 13.3 Decision Evidence
|
|
|
|
Mature systems SHOULD preserve:
|
|
|
|
```text
|
|
policy references
|
|
matched grants
|
|
matched denials
|
|
condition results
|
|
attribute sources
|
|
relationship tuples used
|
|
decision time
|
|
decision point
|
|
enforcement point
|
|
request correlation id
|
|
```
|
|
|
|
## 13.4 Fail-Safe Rule
|
|
|
|
Profiles SHOULD define how to handle indeterminate decisions.
|
|
|
|
Security-sensitive systems SHOULD default to deny unless an explicit profile states otherwise.
|
|
|
|
---
|
|
|
|
# 14. Access-Control Patterns
|
|
|
|
## 14.1 Pattern: Subject-Action-Resource
|
|
|
|
**Context:** A system needs a stable core authorization model.
|
|
|
|
**Problem:** Access rules become inconsistent when subjects, actions, resources, and scopes are mixed together.
|
|
|
|
**Solution:** Represent authorization around:
|
|
|
|
```text
|
|
Subject
|
|
Action
|
|
Resource
|
|
Context
|
|
Decision
|
|
```
|
|
|
|
---
|
|
|
|
## 14.2 Pattern: Organizational Role to Access Role Mapping
|
|
|
|
**Context:** Organizational roles often need access.
|
|
|
|
**Problem:** Treating organizational roles as direct permissions creates hidden privilege.
|
|
|
|
**Solution:** Map OrganizationalRole to AccessRole through explicit grants, bindings, policies, or profiles.
|
|
|
|
---
|
|
|
|
## 14.3 Pattern: Policy Decision / Enforcement Split
|
|
|
|
**Context:** Application code needs authorization but should not hard-code policy logic.
|
|
|
|
**Problem:** Access rules become scattered across services.
|
|
|
|
**Solution:** Separate:
|
|
|
|
```text
|
|
Policy Enforcement Point
|
|
Policy Decision Point
|
|
Policy Administration Point
|
|
Policy Information Point
|
|
```
|
|
|
|
---
|
|
|
|
## 14.4 Pattern: Least Privilege Grant
|
|
|
|
**Context:** A subject needs access to perform work.
|
|
|
|
**Problem:** Broad roles accumulate and become risky.
|
|
|
|
**Solution:** Grant only the needed actions on the needed resources for the needed scope and duration.
|
|
|
|
---
|
|
|
|
## 14.5 Pattern: Just-in-Time Privilege
|
|
|
|
**Context:** Privileged access is needed occasionally.
|
|
|
|
**Problem:** Standing privileged access creates persistent risk.
|
|
|
|
**Solution:** Use temporary, approved, logged, expiring access grants.
|
|
|
|
---
|
|
|
|
## 14.6 Pattern: Break Glass with Review
|
|
|
|
**Context:** Emergency access is required to restore or protect critical systems.
|
|
|
|
**Problem:** Emergency access can become an invisible bypass.
|
|
|
|
**Solution:** Require strong authentication, explicit reason, time limit, logging, post-use review, and remediation of any misuse.
|
|
|
|
---
|
|
|
|
## 14.7 Pattern: Service Account Ownership
|
|
|
|
**Context:** Non-human accounts access systems.
|
|
|
|
**Problem:** Service accounts become orphaned or over-privileged.
|
|
|
|
**Solution:** Every service account should have owner, purpose, scope, permissions, rotation expectation, and review cycle.
|
|
|
|
---
|
|
|
|
## 14.8 Pattern: Agent Access Boundary
|
|
|
|
**Context:** AI or software agents perform actions.
|
|
|
|
**Problem:** Agents may combine tools and permissions in unexpected ways.
|
|
|
|
**Solution:** Agent access must declare supervising actor, allowed tools, resource scope, action scope, safety boundary, logging, and review requirements.
|
|
|
|
---
|
|
|
|
## 14.9 Pattern: Access Review to Remediation
|
|
|
|
**Context:** Access reviews find inappropriate access.
|
|
|
|
**Problem:** Findings do not turn into corrective action.
|
|
|
|
**Solution:** Model:
|
|
|
|
```text
|
|
AccessReview
|
|
-> AccessFinding
|
|
-> AccessRemediationTask
|
|
-> Evidence
|
|
-> AccessCertification
|
|
```
|
|
|
|
---
|
|
|
|
## 14.10 Pattern: Relationship Tuple for Collaboration
|
|
|
|
**Context:** Access depends on relationships such as owner, viewer, editor, parent folder, team membership, or tenant membership.
|
|
|
|
**Problem:** Flat roles cannot express dynamic collaborative access cleanly.
|
|
|
|
**Solution:** Use relationship tuples and relationship-based checks where appropriate.
|
|
|
|
---
|
|
|
|
# 15. Access Profiles
|
|
|
|
## 15.1 Profile Format
|
|
|
|
An Access Profile SHALL declare:
|
|
|
|
```yaml
|
|
id:
|
|
profile_name:
|
|
status:
|
|
implements:
|
|
- InfoTechCanonAccessControlModel
|
|
target_context:
|
|
included_concepts:
|
|
required_relationships:
|
|
required_metadata:
|
|
decision_model:
|
|
source_of_truth_rules:
|
|
mapping_files:
|
|
validation_rules:
|
|
examples:
|
|
known_deviations:
|
|
```
|
|
|
|
---
|
|
|
|
## 15.2 Seed Profile: Small SaaS Access Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Provide a minimal access model for a small SaaS platform moving toward production readiness.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Subject
|
|
Principal
|
|
Resource
|
|
Action
|
|
Permission
|
|
AccessRole
|
|
RoleBinding
|
|
AuthorizationRequest
|
|
AuthorizationDecision
|
|
AccessSession
|
|
AccessReview
|
|
TemporaryAccess
|
|
ServiceAccountAccess
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
Principal maps_to Actor
|
|
AccessRole has_permission Permission
|
|
RoleBinding grants AccessRole to Subject within ResourceScope
|
|
AuthorizationRequest evaluated_by PolicyDecisionPoint
|
|
AuthorizationDecision enforced_by PolicyEnforcementPoint
|
|
AccessReview reviews Grant
|
|
```
|
|
|
|
---
|
|
|
|
## 15.3 Seed Profile: Kubernetes RBAC Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map Kubernetes RBAC objects into InfoTechCanon access-control concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
User / Group / ServiceAccount -> Subject
|
|
Role -> AccessRole scoped to Namespace
|
|
ClusterRole -> AccessRole scoped to Cluster
|
|
RoleBinding -> RoleBinding scoped to Namespace
|
|
ClusterRoleBinding -> RoleBinding scoped to Cluster
|
|
PolicyRule verbs -> Actions
|
|
PolicyRule resources -> ResourceTypes
|
|
Namespace -> ResourceScope
|
|
```
|
|
|
|
Known deviations:
|
|
|
|
```text
|
|
Kubernetes RBAC is additive and does not model explicit deny in standard RBAC.
|
|
Kubernetes subjects may reference identities outside the cluster.
|
|
ClusterRole can be bound namespace-locally through RoleBinding.
|
|
```
|
|
|
|
---
|
|
|
|
## 15.4 Seed Profile: OPA Policy Decision Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map OPA/Rego-style policy decision architecture into InfoTechCanon access-control concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
input -> AuthorizationRequest
|
|
data -> PolicyInformation / PolicyData
|
|
rego policy -> AccessPolicyImplementation
|
|
allow result -> AuthorizationDecision
|
|
OPA server/library -> PolicyDecisionPoint
|
|
application gateway/service -> PolicyEnforcementPoint
|
|
```
|
|
|
|
---
|
|
|
|
## 15.5 Seed Profile: OpenFGA / Zanzibar Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map relationship-based authorization concepts into InfoTechCanon.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
user -> Subject
|
|
object -> Resource
|
|
relation -> RelationshipTuple relation
|
|
tuple -> RelationshipTuple
|
|
authorization model -> Policy / Schema
|
|
check request -> AuthorizationRequest
|
|
check response -> AuthorizationDecision
|
|
```
|
|
|
|
---
|
|
|
|
## 15.6 Seed Profile: Keycloak Authorization Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map Keycloak identity and authorization concepts into InfoTechCanon.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
Realm -> AccessDomain / TenantScope
|
|
Client -> ResourceServer / ClientApplication
|
|
Realm Role -> AccessRole
|
|
Client Role -> AccessRole within ClientScope
|
|
Group -> GroupSubject
|
|
User -> Principal
|
|
Resource -> ProtectedResource
|
|
Scope -> Action / ResourceScope depending on usage
|
|
Policy -> AccessPolicyImplementation
|
|
Permission -> Permission / PolicyBinding
|
|
```
|
|
|
|
---
|
|
|
|
## 15.7 Seed Profile: Cedar / Verified Permissions Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map Cedar-style fine-grained authorization into InfoTechCanon.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
principal -> Subject
|
|
action -> Action
|
|
resource -> Resource
|
|
context -> EvaluationContext
|
|
policy -> AccessPolicyImplementation
|
|
schema -> AccessModelSchema
|
|
permit/forbid -> AuthorizationDecision rule type
|
|
authorization API call -> AuthorizationRequest
|
|
```
|
|
|
|
---
|
|
|
|
## 15.8 Seed Profile: Ops / Break-Glass Access Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent high-risk operational access to infrastructure, production systems, secrets, and emergency tools.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
PrivilegedAction
|
|
TemporaryAccess
|
|
JustInTimeAccess
|
|
BreakGlassAccess
|
|
ApprovalReference
|
|
AccessSession
|
|
SessionRecordingReference
|
|
AccessEvidence
|
|
PostUseReview
|
|
AccessFinding
|
|
AccessRemediation
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
TemporaryAccess approved_by Actor
|
|
BreakGlassAccess requires Reason
|
|
AccessSession evidences AccessUse
|
|
PostUseReview reviews AccessSession
|
|
AccessFinding remediated_by Task
|
|
```
|
|
|
|
---
|
|
|
|
## 15.9 Seed Profile: Agent Access Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Support AI and software agents that act through tools and APIs.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
AgentSubject
|
|
ToolResource
|
|
ActionScope
|
|
ResourceScope
|
|
SupervisingActor
|
|
DelegatedAccess
|
|
TemporaryAccess
|
|
PolicyBinding
|
|
ExecutionEvidence
|
|
HumanReview
|
|
RevocationMechanism
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
AgentSubject supervised_by Actor
|
|
AgentSubject has_permission Permission
|
|
Permission applies_to ToolResource
|
|
Grant constrained_by SafetyCondition
|
|
ExecutionEvidence evidences Action
|
|
HumanReview reviews AgentAccess
|
|
```
|
|
|
|
---
|
|
|
|
# 16. Mapping Model for the Access Control Standard
|
|
|
|
Mappings relate InfoTechCanon access-control concepts to external standards, tools, and products.
|
|
|
|
## 16.1 Mapping Types
|
|
|
|
Recommended mapping types:
|
|
|
|
```text
|
|
exactMatch
|
|
closeMatch
|
|
broadMatch
|
|
narrowMatch
|
|
relatedMatch
|
|
conflictMatch
|
|
gapMatch
|
|
derivedFrom
|
|
regulatoryReference
|
|
toolEquivalent
|
|
```
|
|
|
|
## 16.2 Mapping Record
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
id: itc-map:permission-to-rbac-permission
|
|
source_concept: itc-access:Permission
|
|
target_body: NIST/INCITS RBAC
|
|
target_version: "INCITS 359-2012 / R2022"
|
|
target_concept: Permission
|
|
mapping_type: closeMatch
|
|
scope:
|
|
- role-based access-control modeling
|
|
not_valid_for:
|
|
- attribute-based conditions
|
|
- relationship-based dynamic authorization
|
|
rationale: >
|
|
Both concepts represent an authorization unit combining operations and objects/resources,
|
|
but InfoTechCanon generalizes permission across RBAC, ABAC, ReBAC, and policy-based models.
|
|
confidence: high
|
|
status: candidate
|
|
owner: InfoTechCanonAccessControlModel
|
|
```
|
|
|
|
## 16.3 Seed Mapping Targets
|
|
|
|
The Access Control Model SHOULD maintain mappings to:
|
|
|
|
```text
|
|
NIST / INCITS RBAC
|
|
NIST SP 800-162 ABAC
|
|
XACML 3.0
|
|
OAuth 2.0
|
|
OpenID Connect
|
|
SAML 2.0
|
|
SCIM 2.0
|
|
Kubernetes RBAC
|
|
AWS IAM
|
|
Cedar / Amazon Verified Permissions
|
|
Open Policy Agent / Rego
|
|
OpenFGA
|
|
Google Zanzibar
|
|
Keycloak roles and authorization services
|
|
privacyIDEA policies and MFA concepts
|
|
Casbin model/policy concepts
|
|
Linux users/groups/sudo
|
|
LDAP groups
|
|
GitHub repository roles
|
|
GitLab permissions
|
|
Jira permissions
|
|
Cloud provider IAM models
|
|
```
|
|
|
|
---
|
|
|
|
# 17. Assimilation Hooks
|
|
|
|
The Access Control Model SHALL be able to receive new access-control standards, tools, products, and patterns through the InfoTechCanon assimilation process.
|
|
|
|
## 17.1 Assimilation Triggers
|
|
|
|
Assimilation may be triggered by:
|
|
|
|
```text
|
|
new IAM product
|
|
new authorization framework
|
|
new policy language
|
|
new access-control model
|
|
new cloud provider IAM feature
|
|
new Kubernetes authorization feature
|
|
new DevSecOps access requirement
|
|
new agentic access-control need
|
|
new production-readiness requirement
|
|
new access-control failure
|
|
```
|
|
|
|
## 17.2 Access Assimilation Output
|
|
|
|
An access assimilation SHOULD produce:
|
|
|
|
```text
|
|
source summary
|
|
extracted access concepts
|
|
concept comparison matrix
|
|
gap list
|
|
conflict list
|
|
mapping file
|
|
candidate new concepts
|
|
candidate relationship changes
|
|
candidate pattern changes
|
|
candidate profile changes
|
|
open questions
|
|
```
|
|
|
|
## 17.3 Recommended First Assimilation Candidates
|
|
|
|
```text
|
|
Kubernetes RBAC
|
|
Keycloak role and authorization model
|
|
privacyIDEA policies and MFA model
|
|
NIST RBAC
|
|
NIST ABAC
|
|
OpenFGA / Zanzibar
|
|
OPA / Rego
|
|
Cedar / Amazon Verified Permissions
|
|
SCIM 2.0
|
|
OAuth 2.0 / OIDC
|
|
Linux sudoers
|
|
GitHub repository permissions
|
|
```
|
|
|
|
---
|
|
|
|
# 18. Integration with Other InfoTechCanon Standards
|
|
|
|
## 18.1 Organization Model
|
|
|
|
Access imports organization concepts for:
|
|
|
|
```text
|
|
actor
|
|
person
|
|
agent
|
|
team
|
|
group
|
|
organizational role
|
|
authority
|
|
responsibility
|
|
ownership
|
|
membership
|
|
```
|
|
|
|
## 18.2 Governance Model
|
|
|
|
Access imports governance concepts for:
|
|
|
|
```text
|
|
access policy
|
|
control objective
|
|
control
|
|
approval
|
|
exception
|
|
risk
|
|
evidence
|
|
review
|
|
audit
|
|
compliance requirement
|
|
```
|
|
|
|
## 18.3 Landscape Model
|
|
|
|
Access applies to landscape concepts such as:
|
|
|
|
```text
|
|
service
|
|
repository
|
|
pipeline
|
|
artifact
|
|
runtime resource
|
|
network endpoint
|
|
dataset
|
|
secret
|
|
environment
|
|
platform
|
|
tenant
|
|
```
|
|
|
|
## 18.4 Task Model
|
|
|
|
Access creates or references tasks such as:
|
|
|
|
```text
|
|
access request
|
|
access approval task
|
|
access review task
|
|
access remediation task
|
|
break-glass review task
|
|
agent access review task
|
|
```
|
|
|
|
## 18.5 Tagging Standard
|
|
|
|
Tags may classify access grants, resources, or policies but must not replace access-control relationships.
|
|
|
|
## 18.6 Security Model
|
|
|
|
Security imports access-control concepts for:
|
|
|
|
```text
|
|
privilege escalation
|
|
excess access
|
|
access finding
|
|
identity attack path
|
|
credential misuse
|
|
authorization bypass
|
|
```
|
|
|
|
---
|
|
|
|
# 19. Canon Interface Card Usage
|
|
|
|
Subsystems that implement or produce access-control knowledge SHOULD publish a Canon Interface Card.
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
subsystem: keycape
|
|
implements:
|
|
- InfoTechCanonAccessControlModel
|
|
- SmallSaaSAccessProfile
|
|
produces:
|
|
- Principal
|
|
- AccessRole
|
|
- RoleBinding
|
|
- AuthorizationDecision
|
|
- AccessSession
|
|
consumes:
|
|
- Person
|
|
- Team
|
|
- Policy
|
|
- Service
|
|
relations:
|
|
- Principal maps_to Person
|
|
- Principal assigned_role AccessRole
|
|
- AccessRole has_permission Permission
|
|
- AuthorizationDecision enforced_by Service
|
|
source_of_truth:
|
|
principal_identity: keycape
|
|
role_binding: keycape
|
|
known_deviations:
|
|
- does not model full HR lifecycle
|
|
- does not own governance policy definitions
|
|
```
|
|
|
|
---
|
|
|
|
# 20. Retrieval Requirements
|
|
|
|
The Access Control Model is designed for markdown-based infospaces.
|
|
|
|
## 20.1 Required Retrieval Properties
|
|
|
|
Every major concept SHOULD provide:
|
|
|
|
- stable heading,
|
|
- stable identifier,
|
|
- short definition,
|
|
- longer explanation,
|
|
- examples,
|
|
- distinction notes,
|
|
- relationship examples,
|
|
- mapping hooks,
|
|
- profile references,
|
|
- and common mistakes.
|
|
|
|
## 20.2 Agent Brief
|
|
|
|
A mature Access Control Model SHOULD include an `agent-brief.md` file with:
|
|
|
|
```text
|
|
purpose
|
|
scope
|
|
owned concepts
|
|
imported concepts
|
|
core distinctions
|
|
do / do not rules
|
|
relationship patterns
|
|
minimal examples
|
|
common mistakes
|
|
profile list
|
|
mapping list
|
|
```
|
|
|
|
## 20.3 Indexes
|
|
|
|
The access-control information space SHOULD provide indexes by:
|
|
|
|
```text
|
|
concept
|
|
relationship
|
|
subject type
|
|
resource type
|
|
action
|
|
permission
|
|
role
|
|
grant
|
|
decision
|
|
profile
|
|
pattern
|
|
mapping target
|
|
status
|
|
source system
|
|
```
|
|
|
|
---
|
|
|
|
# 21. Conformance Levels
|
|
|
|
## 21.1 Reference-Conformant
|
|
|
|
A document or system is reference-conformant if it uses Access Control Model terminology consistently but does not implement structured metadata or validation rules.
|
|
|
|
## 21.2 Metadata-Conformant
|
|
|
|
A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.
|
|
|
|
## 21.3 Relationship-Conformant
|
|
|
|
A system is relationship-conformant if it represents subjects, resources, actions, permissions, grants, bindings, decisions, and enforcement as explicit relationships.
|
|
|
|
## 21.4 Decision-Conformant
|
|
|
|
A system is decision-conformant if authorization requests and decisions are represented with subject, action, resource, context, decision value, and policy or reason references.
|
|
|
|
## 21.5 Evidence-Conformant
|
|
|
|
A system is evidence-conformant if access reviews, privileged access, break-glass access, and authorization decisions can be linked to evidence.
|
|
|
|
## 21.6 Profile-Conformant
|
|
|
|
A system is profile-conformant if it implements a declared Access Profile and passes its validation rules.
|
|
|
|
## 21.7 Assimilation-Conformant
|
|
|
|
A system or repository is assimilation-conformant if it can accept external access-control concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.
|
|
|
|
---
|
|
|
|
# 22. Validation Rules
|
|
|
|
Initial validation rules:
|
|
|
|
```text
|
|
VAL-ACCESS-001: Authentication and authorization SHOULD be modeled as distinct concerns.
|
|
|
|
VAL-ACCESS-002: OrganizationalRole MUST NOT be treated as AccessRole unless a mapping or profile declares it.
|
|
|
|
VAL-ACCESS-003: Permission SHOULD identify action, resource, and scope where possible.
|
|
|
|
VAL-ACCESS-004: Grant SHOULD identify subject, permission or role, resource scope, source, and validity period where applicable.
|
|
|
|
VAL-ACCESS-005: AuthorizationRequest SHOULD identify subject, action, resource, and evaluation context.
|
|
|
|
VAL-ACCESS-006: AuthorizationDecision SHOULD record decision value, decision reason, evaluated policy or grant references, and decision point where available.
|
|
|
|
VAL-ACCESS-007: PolicyEnforcementPoint SHOULD be identified for enforced access decisions.
|
|
|
|
VAL-ACCESS-008: Privileged access SHOULD be time-bounded or periodically reviewed.
|
|
|
|
VAL-ACCESS-009: BreakGlassAccess SHOULD require reason, strong authentication, logging, expiry, and post-use review.
|
|
|
|
VAL-ACCESS-010: ServiceAccountAccess SHOULD declare owner, purpose, scope, and review expectation.
|
|
|
|
VAL-ACCESS-011: AgentAccess SHOULD declare supervising actor, allowed actions, resource scope, safety boundary, and evidence requirements.
|
|
|
|
VAL-ACCESS-012: AccessReview SHOULD produce findings or certification evidence.
|
|
|
|
VAL-ACCESS-013: AccessFinding SHOULD create or reference remediation work when correction is required.
|
|
|
|
VAL-ACCESS-014: Tags MUST NOT be treated as entitlements unless an Access Profile explicitly defines that behavior.
|
|
|
|
VAL-ACCESS-015: Imported external access concepts SHOULD be represented through mapping records rather than silently reused.
|
|
|
|
VAL-ACCESS-016: Profiles MUST NOT redefine canonical concepts. They may constrain them.
|
|
|
|
VAL-ACCESS-017: Standing privileges SHOULD be justified by purpose, scope, and review cycle.
|
|
|
|
VAL-ACCESS-018: Orphaned, stale, or excess access SHOULD be detectable in mature implementations.
|
|
```
|
|
|
|
---
|
|
|
|
# 23. Anti-Patterns
|
|
|
|
## 23.1 Login Means Access
|
|
|
|
Assuming that authentication implies authorization.
|
|
|
|
## 23.2 Organizational Role Equals Permission
|
|
|
|
Giving permissions directly based on job titles or informal roles without explicit access mapping.
|
|
|
|
## 23.3 God Role
|
|
|
|
Creating broad administrator roles without scope, review, or justification.
|
|
|
|
## 23.4 Standing Privilege Everywhere
|
|
|
|
Keeping persistent privileged access when temporary or just-in-time access would suffice.
|
|
|
|
## 23.5 Service Account Without Owner
|
|
|
|
Allowing non-human accounts without owner, purpose, expiry, credential rotation, or review.
|
|
|
|
## 23.6 Break Glass Without Glass
|
|
|
|
Emergency access exists but is not time-bounded, logged, reviewed, or exceptional.
|
|
|
|
## 23.7 Policy in Code Only
|
|
|
|
Hard-coding authorization logic in application code without explicit policy model or review path.
|
|
|
|
## 23.8 Token as Truth
|
|
|
|
Treating token claims as always sufficient for authorization without checking resource, context, or policy.
|
|
|
|
## 23.9 Tag-Based Authorization Drift
|
|
|
|
Using uncontrolled labels or tags to grant access.
|
|
|
|
## 23.10 Access Review Theater
|
|
|
|
Running access reviews that do not produce evidence, findings, remediation, or certification.
|
|
|
|
---
|
|
|
|
# 24. Initial Repository Placement
|
|
|
|
Recommended repository layout:
|
|
|
|
```text
|
|
info-tech-canon/
|
|
standards/
|
|
access-control/
|
|
InfoTechCanonAccessControlModel.md
|
|
agent-brief.md
|
|
concepts/
|
|
relationships/
|
|
patterns/
|
|
profiles/
|
|
mappings/
|
|
assimilation/
|
|
examples/
|
|
validation/
|
|
```
|
|
|
|
Seed files:
|
|
|
|
```text
|
|
standards/access-control/InfoTechCanonAccessControlModel.md
|
|
standards/access-control/agent-brief.md
|
|
standards/access-control/concepts/subject.md
|
|
standards/access-control/concepts/resource.md
|
|
standards/access-control/concepts/action.md
|
|
standards/access-control/concepts/permission.md
|
|
standards/access-control/concepts/grant.md
|
|
standards/access-control/concepts/authorization-decision.md
|
|
standards/access-control/concepts/policy-enforcement-point.md
|
|
standards/access-control/concepts/access-review.md
|
|
standards/access-control/patterns/subject-action-resource.md
|
|
standards/access-control/patterns/policy-decision-enforcement-split.md
|
|
standards/access-control/patterns/least-privilege-grant.md
|
|
standards/access-control/patterns/just-in-time-privilege.md
|
|
standards/access-control/profiles/small-saas-access-profile.md
|
|
standards/access-control/profiles/kubernetes-rbac-profile.md
|
|
standards/access-control/profiles/openfga-zanzibar-profile.md
|
|
standards/access-control/profiles/agent-access-profile.md
|
|
standards/access-control/mappings/rbac.yaml
|
|
standards/access-control/mappings/abac.yaml
|
|
standards/access-control/mappings/kubernetes-rbac.yaml
|
|
standards/access-control/mappings/oidc-oauth.yaml
|
|
```
|
|
|
|
---
|
|
|
|
# 25. Roadmap
|
|
|
|
## Phase 1: Seed Stabilization
|
|
|
|
- Establish this standard as `InfoTechCanonAccessControlModel`.
|
|
- Add seed concepts, relationship vocabulary, patterns, and profiles.
|
|
- Define validation rules.
|
|
- Align with Organization, Governance, Landscape, Task, and Tagging.
|
|
|
|
## Phase 2: First Assimilations
|
|
|
|
Recommended first assimilations:
|
|
|
|
```text
|
|
NIST / INCITS RBAC
|
|
NIST SP 800-162 ABAC
|
|
Kubernetes RBAC
|
|
Keycloak roles and authorization services
|
|
privacyIDEA policies and MFA model
|
|
OpenFGA / Zanzibar
|
|
OPA / Rego
|
|
Cedar / Amazon Verified Permissions
|
|
SCIM 2.0
|
|
OAuth 2.0 / OIDC
|
|
```
|
|
|
|
## Phase 3: Profile Maturation
|
|
|
|
- Mature Small SaaS Access Profile.
|
|
- Mature Kubernetes RBAC Profile.
|
|
- Mature Keycloak Authorization Profile.
|
|
- Mature Agent Access Profile.
|
|
- Mature Ops / Break-Glass Access Profile.
|
|
|
|
## Phase 4: Tooling Integration
|
|
|
|
- Generate concept indexes.
|
|
- Generate agent brief.
|
|
- Create machine-readable YAML/JSON exports.
|
|
- Add validation scripts.
|
|
- Use in `user-engine`, `user-accounts`, `user-manager`, `OpsBridge`, `Keycape`, `NetKingdom`, and production-readiness tooling.
|
|
|
|
## Phase 5: Security Integration
|
|
|
|
- Feed access findings into Security Model.
|
|
- Connect access reviews to Governance.
|
|
- Connect privileged actions to observability and audit evidence.
|
|
- Connect access remediation to Task Model.
|
|
|
|
---
|
|
|
|
# 26. Summary
|
|
|
|
The InfoTechCanon Access Control Model is the seed standard for representing authorization semantics across human, system, service, platform, and agentic access.
|
|
|
|
Its most important commitments are:
|
|
|
|
```text
|
|
Separate authentication from authorization.
|
|
|
|
Separate organizational roles from access roles.
|
|
|
|
Represent access as subject, action, resource, context, decision, and enforcement.
|
|
|
|
Support RBAC, ABAC, ReBAC, ACL, PBAC, and hybrid models without being captured by one.
|
|
|
|
Make grants, permissions, decisions, enforcement, sessions, reviews, and evidence explicit.
|
|
|
|
Treat service-account, privileged, temporary, break-glass, and agent access as first-class patterns.
|
|
|
|
Map to external standards and tools without surrendering internal semantic autonomy.
|
|
```
|
|
|
|
This makes the Access Control Model a core seed for production readiness, user management, operational access, security posture, agent boundaries, and interoperable authorization across the InfoTechCanon ecosystem.
|