coulomb/info-tech-canon
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
9883a99f788e3bfa428794dc7adae8ec2ac8e6e3
info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md

49 KiB
Raw Blame History

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:

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:

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.

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:

Person
Agent
Team
Organization
Role
Membership
Assignment
Authority
Responsibility
Accountability
Ownership
Stewardship

The Access Control Model owns:

Subject
Principal
AccessRole
Permission
Privilege
Entitlement
Grant
RoleBinding
PolicyBinding
AuthorizationRequest
AuthorizationDecision
EnforcementPoint
AccessSession
AccessReview
AccessExceptionReference

Boundary rule:

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:

Policy
Control
ControlObjective
Decision
Approval
Exception
Risk
Evidence
Review
Audit
ComplianceRequirement

The Access Control Model uses governance concepts for:

access policy references
access-control objectives
access reviews
access exceptions
access evidence
access approvals
risk-based access decisions

Boundary rule:

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:

Service
ApplicationService
Repository
RuntimeResource
Endpoint
DataStore
Dataset
Environment
NetworkResource
PlatformResource

The Access Control Model refers to these as protected resources.

Boundary rule:

Landscape owns resource identity and relationships.
Access Control owns access semantics for those resources.

3.4 Boundary with Security

The Security Model should own:

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:

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:

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:

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:

---
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:

idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired

Recommended concept statuses:

proposed
experimental
candidate
canonical
deprecated
retired

10. Root Access-Control Taxonomy

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:

id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:

Optional attributes:

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:

human user
service account
workload identity
AI agent
automation bot
group
federated identity
external partner

Canonical rule:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

subject:
action:
resource:
context:
requested_at:
request_source:

11.21 AuthorizationDecision

An AuthorizationDecision is the result of evaluating an authorization request.

Recommended decision values:

permit
deny
not_applicable
indeterminate
conditional_permit

Recommended attributes:

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:

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:

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:

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:

subject relation object

Examples:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

subject:
action:
resource:
context:
  time:
  environment:
  session:
  authentication_strength:
  network:
  device:
  risk:
  purpose:
  request_source:

13.2 Authorization Decision Values

Recommended decision values:

permit
deny
not_applicable
indeterminate
conditional_permit

13.3 Decision Evidence

Mature systems SHOULD preserve:

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:

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:

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:

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:

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:

Provide a minimal access model for a small SaaS platform moving toward production readiness.

Included concepts:

Subject
Principal
Resource
Action
Permission
AccessRole
RoleBinding
AuthorizationRequest
AuthorizationDecision
AccessSession
AccessReview
TemporaryAccess
ServiceAccountAccess

Required relationships:

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:

Map Kubernetes RBAC objects into InfoTechCanon access-control concepts.

Example mappings:

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:

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:

Map OPA/Rego-style policy decision architecture into InfoTechCanon access-control concepts.

Example mappings:

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:

Map relationship-based authorization concepts into InfoTechCanon.

Example mappings:

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:

Map Keycloak identity and authorization concepts into InfoTechCanon.

Example mappings:

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:

Map Cedar-style fine-grained authorization into InfoTechCanon.

Example mappings:

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:

Represent high-risk operational access to infrastructure, production systems, secrets, and emergency tools.

Included concepts:

PrivilegedAction
TemporaryAccess
JustInTimeAccess
BreakGlassAccess
ApprovalReference
AccessSession
SessionRecordingReference
AccessEvidence
PostUseReview
AccessFinding
AccessRemediation

Required relationships:

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:

Support AI and software agents that act through tools and APIs.

Included concepts:

AgentSubject
ToolResource
ActionScope
ResourceScope
SupervisingActor
DelegatedAccess
TemporaryAccess
PolicyBinding
ExecutionEvidence
HumanReview
RevocationMechanism

Required relationships:

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:

exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
toolEquivalent

16.2 Mapping Record

Example:

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:

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:

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:

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

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:

actor
person
agent
team
group
organizational role
authority
responsibility
ownership
membership

18.2 Governance Model

Access imports governance concepts for:

access policy
control objective
control
approval
exception
risk
evidence
review
audit
compliance requirement

18.3 Landscape Model

Access applies to landscape concepts such as:

service
repository
pipeline
artifact
runtime resource
network endpoint
dataset
secret
environment
platform
tenant

18.4 Task Model

Access creates or references tasks such as:

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:

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:

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:

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:

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:

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:

info-tech-canon/
  standards/
    access-control/
      InfoTechCanonAccessControlModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/

Seed files:

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:

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:

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.

Reference in New Issue View Git Blame Copy Permalink