summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/share/authz/ABAC.md57
-rw-r--r--doc/share/authz/DESIGN.md194
-rw-r--r--doc/share/authz/EXPERIMENT.md42
-rw-r--r--doc/share/authz/FAQ.md33
-rw-r--r--doc/share/authz/POLICY.md124
-rw-r--r--doc/share/authz/RBAC.md103
-rw-r--r--doc/share/authz/README.md69
-rw-r--r--doc/share/authz/ReBAC.md149
-rw-r--r--doc/share/authz/SLIDES.md207
-rw-r--r--doc/share/authz/ZANZIBAR.md51
-rw-r--r--doc/share/authz/todo/001_ldap.md19
-rw-r--r--doc/share/authz/todo/002_hierarchical_membership.md19
-rw-r--r--doc/share/authz/todo/003_workload_identity_federation.md21
-rw-r--r--doc/share/authz/todo/004_acme_protocol.md69
-rw-r--r--doc/share/authz/todo/005_open_pubkey.md20
-rw-r--r--doc/share/authz/todo/006_zero_knowledge_proof.md17
16 files changed, 0 insertions, 1194 deletions
diff --git a/doc/share/authz/ABAC.md b/doc/share/authz/ABAC.md
deleted file mode 100644
index 791fdeff..00000000
--- a/doc/share/authz/ABAC.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# Attribute-Based Access Control (ABAC)
-
-> Attribute-based access control (ABAC) is considered one of th emost generalized
-> forms of access control as it can capture the salient features of discretionary
-> access (DAC), mandatory access control (MAC) and role-based access control
-> (RBAC) using appropriate attributes such as access control lists, security
-> labels and roles respectively. [5]
-
-ABAC has been studied for a long time and many different formal models have been
-proposed.
-
-ABAC is a logical access control model that is distinguishable because it
-controls access to objects by evaluating rules against the attributes of
-entities (subject and object), operations, and the environment relevant to a
-request.
-
-As new subjects join the organization, rules and objects do not need to be
-modified. As long as the subject is assigned the attributes necessary for access
-to the required objects, no modifications to existing rules or object attributes
-are required.
-
-There can be three types of attributes:
-
-1. Atomic-values or single valued attribute:
-1. Set-valued or multi-valued attribute:
-1. Structured Attribute:
-
-Attributes can be either:
-
-* Entity Attribute: a thing that can be distinctly identified.
-* Non-entity Attribute: whose range is not defined on the set of entities in the
- system.
-
-The range of an attribute is bounded or not:
-
-* Finite Domain Attribute: Range of this attribute type is a finite set of
- attribute value.
-* Infinite Domain Attribute: Range of this attribute type is a countably
- infinite set of attribute values.
-
-## Weaknesses
-
-It is often claimed that attributes can express relationships, and indeed this
-is trivial for direct relationships. However, the use of indirect relations,
-also called multilevel or composite relations, is fundamental to ReBAC. It is
-hard to see how ABAC can express long chains of relationships. It has been
-suggested that ReBAC emerged to overcome this shortcoming of attributes.
-
-## See Also
-
-* [Classifying and Comparing Attribute-Based and Relationship-Based Access Control][5]
-* [A Capability-based Distributed Authorization System to Enforce Context-aware Permission Sequences][6]
-* [Guide to Attribute Based Access Control (ABAC) Definition and Considerations][7]
-
-[5]: https://dl.acm.org/doi/pdf/10.1145/3029806.3029828
-[6]: https://dl.acm.org/doi/pdf/10.1145/3532105.3535014
-[7]: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf
diff --git a/doc/share/authz/DESIGN.md b/doc/share/authz/DESIGN.md
deleted file mode 100644
index 51129a1c..00000000
--- a/doc/share/authz/DESIGN.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# Design
-
-## Current
-
-### Architecture
-
-```plaintext
- -------------
- | user-agent |
- -------------
- |
- V
-----|:443|------------------------------
- |
- V------------|
- | |
- |------| |
- V V V
- | ----------------------------
- |--->| authn | CI | ... | authz |
- V |--------------------------|
- |--->| UI | REST API | ... |
- | ----------------------------
- V A
- | |
- |---->---->---
-```
-
-## Proposed
-
-### Architecture
-
-```plaintext
- -------------
- | user-agent |
- -------------
- |
- V
-----|:8080|-----------------------------------------------
- |
- V
- ---------------
- | API Gateway |
- ---------------
- |
- | ---------------------------------
- | | IdP (saml, oidc) |
- | |-------------------------------|
- |--->| :http (authn) | :grpc (authz) |
- | ---------------------------------
- | A
- ----------- |
- | | |
- V V |
- ------ ------------ |
- | UI | | REST API |----------|
- ------ ------------ |
- | A
- |---->----------->------------|
-
-[UI]: ui.example.com
-[REST API]: api.example.com
-[IdP]: idp.example.com
-```
-
-SAML Login Flow
-
-```plantuml
-@startuml
-Browser -> UI: 1. Get dashboard
-UI --> Browser: Generate SAML <AuthnRequest /> and redirect to IdP
-
-Browser -> IdP: 2. Deliver SAML <AuthnRequest />
-IdP --> Browser: 3. Redirect to Login Page
-Browser -> IdP: 4. Login
-IdP --> Browser: 5. Generate SAML <AuthnResponse /> with <Assertion /> and redirect to UI
-
-Browser -> UI: 6. Deliver SAML <AuthnResponse />
-UI -> IdP: 7. Exchange <Assertion /> for Tokens
-IdP --> UI: Return `access_token` and `refresh_token`
-UI --> Browser: Redirect to dashboard
-Browser -> UI: Get dashboard
-UI -> API: 8. Request list of groups and provide Access Token
-API -> IdP: 9. Check if token is valid and check declarative policy
-IdP --> API: Return result of `Ability.allowed?`
-API --> UI: Return list of groups as JSON
-UI --> Browser: Return list of groups as HTML
-@enduml
-```
-
-1. `GET http://ui.example.com/saml/new`
-2. `POST http://idp.example.com/saml/new`
-3. `GET http://idp.example.com/sessions/new?redirect_back=/saml/continue`
-4. `POST http://idp.example.com/sessions`
-5. `GET http://idp.example.com/saml/continue`
-6. `POST http://ui.example.com/saml/assertions`
-7. `POST http://idp.example.com/oauth/token`
-8. `GET http://api.example.com/groups.json`
-9. `GET grpc://idp.example.com/twirp/authx.rpc.Ability/Allowed`
-
-OIDC Login Flow
-
-```plantuml
-@startuml
-Browser -> UI: 1. Get dashboard
-UI --> Browser: Generate OAuth Grant Request and redirect to IdP
-
-Browser -> IdP: 2. Deliver OAuth Grant Request
-IdP --> Browser: 3. Redirect to Login Page
-Browser -> IdP: 4. Login
-IdP --> Browser: 5. Generate Consent Screen for Authorization Code flow
-Browser -> IdP: 6. Consent
-IdP --> Browser: Generate Authorization Code and redirect to UI
-
-Browser -> UI: 7. Deliver Authorization Code Grant
-UI -> IdP: 8. Exchange Authorization Code Grant for Tokens
-IdP --> UI: Return `access_token` and `refresh_token`
-UI --> Browser: Redirect to dashboard
-Browser -> UI: Get dashboard
-UI -> API: 9. Request list of groups and provide Access Token
-API -> IdP: 10. Check if token is valid and check declarative policy
-IdP --> API: Return result of `Ability.allowed?`
-API --> UI: Return list of groups as JSON
-UI --> Browser: Return list of groups as HTML
-@enduml
-```
-
-1. `GET http://ui.example.com/oidc/new`
-2. `GET http://idp.example.com/oauth/authorize`
-3. `GET http://idp.example.com/sessions/new?redirect_back=/oauth/authorize/continue`
-4. `POST http://idp.example.com/sessions`
-5. `GET http://idp.example.com/oauth/authorize/continue`
-6. `POST http://idp.example.com/oauth/authorize`
-7. `GET http://ui.example.com/oauth/callback`
-8. `POST http://idp.example.com/oauth/token`
-9. `GET http://api.example.com/groups.json`
-10. `GET grpc://idp.example.com/twirp/authx.rpc.Ability/Allowed`
-
-### Permissions
-#### Option 1
-
-| permission | scope | description |
-| ---------- | ----- | ----------- |
-| `read` | `gid://app/Organization/1` | Can read Org 1 resource |
-| `read` | `gid://app/Organization/1/*` | Can read every resource below Org 1 hierarchy |
-| `read` | `gid://app/Organization/1/Group/1` | Can read Group 1 resource |
-| `read` | `gid://app/Organization/1/Group/1/*` | Can read every resource below Group 1 hierarchy |
-| `read` | `gid://app/Organization/1/Group/1/Project/1` | Can read project 1 |
-| `read` | `gid://app/Project/1` | Can read project 1 resource (short circuit example) |
-| `read` | `gid://app/Organization/1/Group/1?attributes[]=name&attributes[]=description` | Can read name and description of Group 1 resource |
-
-Example:
-
-The following example allows the subject of the token to read all of the descendant resources of `Project 1` and `Project 2` and it can read `Project 3`.
-
-```json
-{
- "sub": "gid://User/17",
- "scope": {
- "read": [
- "gid://app/Organization/1/Group/1/Project/1/*",
- "gid://app/Organization/1/Group/1/Project/2/*",
- "gid://app/Organization/1/Group/2/Project/3"
- ]
- }
-}
-```
-
-#### Option 2
-
-Encode access and scope directly into the name of the permission.
-
-| permission | description |
-| ---------- | ----------- |
-| `read:organization:1` | Can read Org 1 resource |
-| `read:organization:1:*` | Can read every resource below Org 1 hierarchy |
-| `read:organization:1:group:*` | Can read Group 1 resource |
-| `read:organization:1:group:1:*` | Can read every resource below Group 1 hierarchy |
-| `read:organization:1:group:1:project:1` | Can read project 1 |
-| `read:project:1` | Can read project 1 resource (short circuit example) |
-| `read:organization:1:group:1:attributes[]=name&attributes[]=description` | Can read name and description of Group 1 resource |
-
-Example:
-
-```json
-{
- "sub": "gid://User/17",
- "scope": [
- "read:organization:1:group:1:project:1:*",
- "read:organization:1:group:1:project:2:*",
- "read:organization:1:group:2:project:3"
- ]
-}
-```
diff --git a/doc/share/authz/EXPERIMENT.md b/doc/share/authz/EXPERIMENT.md
deleted file mode 100644
index 0460fe39..00000000
--- a/doc/share/authz/EXPERIMENT.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## Experiments
-
-### Twirp + gRPC (AuthZ)
-
-This experiment exposes a gRPC endpoint that aligns with the [`Ability.allowed?(subject, permission, resource)`][1] interface from GitLab's declarative authorization logic.
-
-It demonstrates a headless authorization service that provides a low-latency decision point for other services to verify permissions.
-
-Actors in this experiment:
-
-* Headless authz service: A facade over GitLab’s existing declarative policies.
-* API (Resource Server in OAuth terms): A slimmed-down GitLab REST API that delegates authorization decisions to the authz service.
-
-### SAML, OIDC, OAuth
-
-This experiment showcases how a separate authx service can handle both authentication and authorization using standard protocols:
-
-* SAML & OIDC for authentication
-* OAuth for authorization
-
-Actors in this experiment:
-
-* Authx service: Acts as a SAML Identity Provider and an OAuth Authorization Server.
-* API: A slimmed-down GitLab REST API.
-
-### API Gateway
-
-This experiment explores a stateless authorization mechanism by integrating a policy DSL (such as [Casbin][3]) into a reverse proxy.
-Authorization decisions are made early in the request pipeline based on HTTP request headers and body content.
-
-### Sidecar Process
-
-This experiment demonstrates a sidecar approach for making authorization decisions within an nginx process.
-Inspired by [Open Policy Agent][4] deployments. This experiment:
-
-* Uses lua bindings in nginx to connect to a local client process.
-* The client process proxies requests to a gRPC based policy decision service.
-
-
-[1]: https://gitlab.com/gitlab-org/gitlab/-/blob/e1f6db024561e35462ac8d9f54b8f9678f6ed6ee/app/models/ability.rb#L73
-[3]: https://casbin.org/
-[4]: https://www.openpolicyagent.org/
diff --git a/doc/share/authz/FAQ.md b/doc/share/authz/FAQ.md
deleted file mode 100644
index 8e73beb2..00000000
--- a/doc/share/authz/FAQ.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Frequently Asked Question (FAQ)
-
-* Q: Are there permissions that do not cascade down the group hierarchy?
-* Q: How do we define the scope of a permission? (hierarchical?)
-* Q: What is the unique identifier for each security principal across service boundaries? (i.e. bigint, ulid, uuid, email)
-* Q: What permissions do each of the standard roles have today?
-* Q: How does a permission cascade down a group hierarchy?
-
-```
-Organization
- Group A
- * Roles
- * Developer
- * Maintainer
- * Custom A
- * base: developer
- * permissions:
- * admin_vulnerability: true
- * read_vulnerability: true (implicitly)
- * Custom B
- * base: maintainer
- * permissions:
- * Doesn't really matter because Maintainer has all the permissions available via a custom role. <- Fact check this
- Group Aa
- Project Aa1
- Project Aa2
- Group Aaa
- Project Aaa1
- Project Aaa2
-```
-
-* Q: If a user has a membership at `Group A`, does the permissions associated with that
-membership cascade down to `Group Aa` and `Group Aaa`?
diff --git a/doc/share/authz/POLICY.md b/doc/share/authz/POLICY.md
deleted file mode 100644
index ab2e8f1a..00000000
--- a/doc/share/authz/POLICY.md
+++ /dev/null
@@ -1,124 +0,0 @@
-# Policy
-
-> Policy is a planned system of rules and guidelines that directs users and automation to execute within purposeful boundaries. [1][1]
-
-The parts of a policy include: [1][1]
-
-* name: used to label the policy for future reference
-* purpose: the reason this policy exists
-* situation: the context in which the policy will be used
-* rules: individual controls or prescribed behaviours;
-* actions: action taken if a policy rule is violated
-
-> A policy is a statement that declares which principals are explicitly
-> permitted, or explicitly forbidden, to perform an action on a resource. - [2][2]
-
-## Policy Language
-
-A policy language facilitates: [3][3]
-
-1. the specification of composite policies, which in turn forms the basis of trust delegation.
-1. **the static analysis of policies and system configuration.**
-
-### Policy as Code (PaC)
-
-These are policies that are written, stored, managed and interpreted as code
-artifacts.
-
-> A policy engine is a program or process that is able to ingest
-> machine-readable policies and apply them to a particular problem domain to
-> constrain the behaviour of network resources. [1][1]
-
-PaC policy engine characteristics: [1][1]
-
-* Ingeting machine-readable policies (PaC)
-* Applying policies to specific problem domains (data)
-* Constraining behaviors (outcomes)
-
-```plaintext
- ----------
- | Policy |--------- A
- ---------- | / \
- V / \
- -------- --------- / \ -------------- --------
- | Data |------>| Input |--->< match >--->| Evaluation |--->( Outcom )
- -------- --------- \ / -------------- --------
- A \ /
- --------- | \ /
- | Query |---------- V
- ---------
-```
-
-Selection Criteria: [1][1]
-
-* Alignment
- - Technical Capabilities of team.
- - Internal strategy for how tools and applications are adopted/managed.
- - Fits the need and internal standards driving the decision
- - Primary use cases match our use cases
-* Analytics
- - logging
- - metrics
- - auditing
-* Automation
- - CI/CD Pipelines
- - Automated Deployments
-* Documentation
- - Examples
- - Patterns
- - Understandable
-* Adoption
- - Who is using this?
- - How much adoption has this project seen?
- - Active?
- - Project Maturity
- - Support Model
- - Intuitive
-* Complexity
- - Installation
- - Deployment
- - Configuration
- - Operation Modes (server, library, CLI)
-* Reporting
- * Standard reporting tools e.g. [OSCAL](https://pages.nist.gov/OSCAL/)
-* Security
- * Risks, vulnerabilities
- * Tools and processes for security issue discovery
-* Extensibility
- * Can custom code be written to extend the language.
-
-Scorecard [1][1]
-
-| Selection Criteria | Casbin | Cedar | Rego |
-| ------------------ | ------ | ----- | ---- |
-| Alignment | | | |
-| Analytics | | | |
-| Adoption | | | |
-| Automation | | | |
-| Documentation | | | |
-| Complexity | | | |
-| Reporting | | | |
-| Security | | | |
-| Extensibility | | | |
-| Total | | | |
-
-### Cedar
-
-### Rego
-
-[Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) is a declarative assertion language that provides reasoning. This is a DSL
-for applying reasoning and assertions to domain-agnostic, structured data.
-
-* [Regorus](https://github.com/microsoft/regorus)
- * [Go binding](https://github.com/microsoft/regorus/tree/main/bindings/go)
- * [Ruby binding](https://github.com/microsoft/regorus/tree/main/bindings/ruby)
-
-## See Also
-
-* [Zanzibar](./ZANZIBAR.md)
-* [Dafny](https://dafny.org)
-* [Policy as Code by Jimmy Ray][1]
-
-[1]: https://learning.oreilly.com/library/view/policy-as-code/
-[2]: https://docs.cedarpolicy.com/overview/terminology.html#term-policy
-[3]: https://ucalgary.scholaris.ca/server/api/core/bitstreams/833a86a8-eb7f-4c50-af4d-696b8deb6fd8/content
diff --git a/doc/share/authz/RBAC.md b/doc/share/authz/RBAC.md
deleted file mode 100644
index 2f0054a6..00000000
--- a/doc/share/authz/RBAC.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Role-Based Access Control (RBAC)
-
-Assigns permissions to roles, which are collections of permissions related to specific job functions. [1][1]
-
-This style of access control aligns with how humans organize themselves within
-organizations by assigning job functions to roles. This model is simple and
-aligns well with how humans operate within their job function.
-
-This model also helps to align security objectives with higher level
-organizational policy (.e.g. ethics, privacy, administration). This type of
-model requires centralized control and enforcement.
-
-> The act of granting membership and specifying transactions for a role is loosely
-> analogous to the process of clearing users (granting membership) and the
-> labeling (associate operation sensitivities) of objects ... - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
-
-> A role can be thought of as a set of transactions that a user or set of users
-> can perform within the context of an organization. - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
-
-Roles are group oriented and they provide a means of naming and describing
-many-to-many relationships between individuals and rights.
-
-1. For each subject, the active role is the one that the subject is currently using:
-
- ```
- AR(s: subject) = { the active role for subject s}.
- ```
-
-2. Each subject may be authorized to perform one or more roles:
-
- ```
- RA(s: subject) = { authorized roles for subject s }.
- ```
-
-3. Each role may be authorized to perform one or more transactions:
-
- ```
- TA(r: role) = { transactions authorized for role r}.
- ```
-
-4. Subjets may execute transactions. The predicate `exec(s,t)` is true if
- subject `s` can execute transaction `t` at the current time, otherwise it is
- false:
-
- ```
- exec(s :subject, t: tran) = true iff subject `s` can execute transaction `t`
- ```
-
-Three basic rules are required:
-
-1. Role assignment: A subject can execute a transaction only if the subject has
- selected or been assigned a role
-2. Role authorization: A subject's active role must be authorized for the
- subject
-3. Transaction authorization: A subject can execute a transaction only if the
- transaction is authorized for the subject's active role
-
-Another user of RBAC is to support integrity. One aspect of integrity is a
-requirement that data and processes be modified only in authorized ways by
-authorized users.
-
-The problem of determining whether data have been modified only in authorized
-ways can be as complex as the transaction that did the modification. For this
-reason, the practical approach is for transactions to be certified and
-trusted. If transactions must be trusted then _access control can be incorporated
-directly into each transaction_.
-
-RBAC makes a decision based on the subject's association with a role. RBAC does
-not easily support multi-factor decisions. RBAC role assignments tend to be
-based upon more static organizational positions, presenting challenges in
-certain RBAC architectures where dynamic access control decisions are required
-(.e.g. `CI_JOB_TOKEN`). Trying to implement these kidns of access control
-decisoins would require the creation of numerous roles that are ad hoc and
-limited in membership, leading to what is often termed "role explosion".
-
-ABAC avoids the need for explicit authorizations to be directly assigned to
-individual subjects prior to a request to perform an operation on the object.
-
-> ABAC: An access control method where subject requests to perform operations on
-> objets are granted or denied based on assigned attributes of the subject,
-> assigned attributes of the object, environment conditions, and a set of
-> policies that are specified in terms of those attributes and conditions.
-
-* Attributes: characteristics of the subject, object, or environment conditions.
-* Subject: is a human or or non-person entity (NPE) that issues access requests
- to perform operations on objects.
-* Object: a system resource for which access is managed by the ABAC system
-* Operation: is the execution of a function at the request of a subject upon an
- object. (e.g. read, write, edit, delete, copy, execute and modify)
-* Policy: is the representation of rules or relationships that makes it possible
- to determine if a requested access should be allowed.
-* Environment conditions: operational or situational context in which the access
- request occurs.
-
-> Roles can inherit from each other and imply permissions. - [1][1]
-
-## See also
-
-* [Role-Based Access Controls][1]
-* [Zanzibar][2]
-
-[1]: https://csrc.nist.gov/files/pubs/conference/1992/10/13/rolebased-access-controls/final/docs/ferraiolo-kuhn-92.pdf
-[2]: https://storage.googleapis.com/gweb-research2023-media/pubtools/5068.pdf
diff --git a/doc/share/authz/README.md b/doc/share/authz/README.md
deleted file mode 100644
index 5b7da3fb..00000000
--- a/doc/share/authz/README.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# Authz
-
-## Access Control Models
-
-Access Controls provide a means of restricting access to objects based on the
-identity of subjects and/or groups to which they belong.
-
-* Role-Based Access Control ([RBAC](./RBAC.md))
-* Relationship-Based Access Control ([ReBAC](./ReBAC.md))
-* Attribute-Based Access Control ([ABAC](./ABAC.md))
-
-Authentication (Authn) is used to determine that users or systems are who they
-claim to be and provide proof in the form of identity principals and attributes.
-
-Authorization (Authz) is used to decide what privileges an actor has within a
-system.
-
-## Policy
-
-* [What is a policy?](./POLICY.md)
-* Policy Language Evaluation
- * Casbin
- * Cedar
- * [Dafny](https://dafny.org/)
- * Rego
-
-Criteria for evaluating policy languages:
-
-* Must be able to model different types of access control models (RBAC, ReBAC, ABAC)
-* Must be able to perform static analysis
-* Must be actively supported
-* Must have concise documentation
-* Must provide ability to extend language using Ruby/Golang for describing complex policies.
-* Must have a compatible license that permits the way that we can use it.
-
-Ideally, we must be able to model the following relationships:
-
-| type | required |
-| ---- | -------- |
-| `user-to-resource` | required |
-| `resource-to-resource` | required |
-| `user-to-user` | not required |
-
-Note: `user-to-user` relationships are not in the current access control model.
-
-## Architecture
-
-```plaintext
- ------------------ ------- -------------
- | Users/Services |--->| PEP |--->| Resources |
- ------------------ ------- -------------
- | A
- V |
- ------- ------------ -------
- | PDP |-->| Policies |<---| PAP |
- ------- ------------ -------
- | A A
- V | |
- ------- -----------------
- | PIP | | Administrator |
- ------- -----------------
-
-PAP: Policy Administration Point
-PDP: Policy Decision Point
-PEP: Policy Enforcement Point
-PIP: Policy Information Point
-```
-
-* [Kubernetes Policy Management](https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/papers/policy/kubernetes-policy-management.pdf)
diff --git a/doc/share/authz/ReBAC.md b/doc/share/authz/ReBAC.md
deleted file mode 100644
index 9202e0c4..00000000
--- a/doc/share/authz/ReBAC.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Relationship-Based Access Control (ReBAC)
-
-> Authorization decisions are based on the relationship between the resource owner
-> and the resource accessor in a social network maintained by the protection
-> system. [1]
-
-A Social Network System (SNS) maintains a social network for at least two reason:
-
-1. It is used by the users to navigate the information space of the system
-2. The social network is used as a basis for formulating the access control
- policies of user contributed resources.
-
-Access Control Paradigm:
-
-1. the explicit tracking of one or more social networks by the protection system
-1. the expression of access control policies in terms of the relationship
- between the resource owner and the resource accessor
-
-Suited for domains in which relationship and authorization decisions are from
-the structure of trust that is inherent in the application domain rather than
-subjective assessment of users.
-
-It is more natural to base authz decisions on whether the resource owner and
-accessor are in a particular kind of relationship.
-
-In a standard RBAC system, when a permission `p` is assigned to role `R`, we are
-essentially formulating the following policy: `grant p to user u if R(u)`.
-
-PriMA is another recently proposed privacy protection mechanism for SNSs.
-
-Unlike [RBAC][4] and [ABAC][3], ReBAC policies deal with relational policies
-rather than unary predicates on attributes and roles.
-
-In, Online Social Network (OSN) applications, authorization for users' access to
-specific content is typically based on ther interpersonal relationships between
-the accessing user and content owner. OSN ReBAC models user user-to-user
-relationships.
-
-The user of indirect relations, also called multilevel or composite relations,
-is fundamental to ReBAC (e.g. friend of friend).
-
-Recently, researchers have proposed extended ReBAC models applicable to other
-computing systems beyond OSNs.
-
-Most ReBAC models consider `user-to-user` and possibly `user-to-resource`
-relationshps. Very few consider `resource-to-resource` relationships. Models
-that consider `resource-to-resource` relationships typically do so through
-users.
-
-## Access Control Policies
-
-Let `U` be the set of all users in the system.
-Accesses are directed against resources. A resource may represent one or more
-objects or certain system operations. Let `R` be the set of resources protected
-by the SNS. A typical member of `R` is denoted by `r`.
-
-Assocated with every access request are therefore the following:
-
-* a protected resource that is being accessed
-* the owner of that resource
-* the accessor of that resource who requests access.
-
-Owner of a resource implies that the accessor must be in a specific kind of
-relationship with the owner in order be granted. Huh?
-
-Associated with every resource is an `access control policy`.
-Policy is modeled as a ternary predicate: `U x U x G(U, I) => {0, 1}`.
-
-## Protection System
-
-A protection system `N` is a 7-tuple `(I, U, R, C, C0, policy, owner)` where:
-
-* `I` is the set of relation identifiers (See my question in the README about resource identifiers in our system)
-* `U` is a finite set of users in the system
-* `R` is a finite set of resources to be protected by the system.
-* `C` is a _infinite_ universe of `access contexts`.
- * `C0` is the root context. (* Could this be the root `Organization` that a `User` belongs to?)
-* `R => PP(U, I)` assigns a policy predicate to every resource in the system. (This means that every resource is addressable through a universal identifier, right? Goodbye `bigint`? Yay!)
-* `owner: R -> U` is a function that assigns an owner to every resource in the system.
-
-Where the access control policy of a resource comes from doesn't matter. The
-possibilities are:
-
-1. Mandatory: Some policies are mandated by the system administrator
-1. Discretionary: The resource owners are responsible for specifying their
- access control policies
-1. Policy Vocabulary: A set of policy predicates from which users take their
- picks. (friends, friends-of-friends)
-
-## Protection State
-
-Given a protection system `N = {I,U,R,C,C0,policy,owner}`, a protection state is
-a triple `{C,sn,extends}` composed of the following elements:
-
-* `C`: is the set of active contexts in the state. This set is infinite and
- non-empty.
-* function `sn : C -> G(U,I)` that maps each context of the state to a social
- network `sn(s)` records the relationships that have been articulated in
- context `c`.
-* `extends ~= C x C` is a binary relation defined over `C`, such that:
- * a: the directed graph is a tree
- * b: `c0` is the root of the tree
- * c: if `(c1,c2) ~= extends` then `c1` is the child of `c2` in the tree. The
- extends relationship defines a **context hierarchy**.
-
-## Authorization
-
-Authz is achieved by consulting relationships in a social network. Authorization
-decisions are made primarily by consulting the relationship between accessor and
-the owner. In a real implementations, it is possible for the system to have a
-hybrid authorization scheme that is both relationship based and role based.
-
-Relationship inheritance allows relationships articulated in ancestor contexts
-to be inherited by the effictive social network of descendant contexts. The
-social network of a child context contains no less relationships than that of a
-parent context.
-
-## Policy Language
-
-It is desirable to have a [policy language](./POLICY.md) for specifying ReBAC policies.
-
-A policy language facilitates:
-
-1. the specification of composite policies, which in turn forms the basis of trust delegation.
-1. **the static analysis of policies and system configuration.**
-
-## Context Hierarchy
-
-The context hierarchy assumes a tree shape: i.e., only single inheritance is permitted.
-Multiple inheritance corresponds to a more flexible means of constraining when
-relationships can be "activated" simultaneously.
-
-## Conclusion
-
->Relationship-Based Access Control works best in application domains in which
->binary relations are more natural for expressing authorization decisions than
->unary relations (e.g., roles).
-
-## See also
-
-* [Relationship-Based Access Control: Protection Model and Policy Language by Philip W. L. Fong][1]
-* [Learning Relationship-Based Access Control Policies from Black-Box Systems][2]
-* [Classifying and Comparing Attribute-Based and Relationship-Based Access Control][5]
-
-[1]: https://cspages.ucalgary.ca/~pwlfong/Pub/codaspy2011.pdf
-[2]: https://dl.acm.org/doi/pdf/10.1145/3517121
-[3]: ./ABAC.md
-[4]: ./RBAC.md
-[5]: https://dl.acm.org/doi/pdf/10.1145/3029806.3029828
diff --git a/doc/share/authz/SLIDES.md b/doc/share/authz/SLIDES.md
deleted file mode 100644
index c14387bc..00000000
--- a/doc/share/authz/SLIDES.md
+++ /dev/null
@@ -1,207 +0,0 @@
-# Authx = Authn + Authz
-
-* Authentication: Are you who you say you are?
-* Authorization: Are you allowed to do that?
-
-# Authx - Examples
-
-1. Travel by Plane (High security context)
- * Authentication: Passport
- * Authorization: Boarding Pass
-1. Travel by Bus (Low security context)
- * Authentication: Not required
- * Authorization: Bus ticket
-
-# Authx
-
-The Resource Server provides the security context and knows if the resource that
-is being access requires a high or low security context.
-
-# Authx
-
-Not every resource requires a high security context.
-
-i.e. we don't need to make a network call to the PDP for every single authorization decision if the security context is low.
-
-# Authx - Challenges
-
-* PKI: key rotation, revocation, signing, encryption
-* Uptime Guarantees
-* Auditability
-* Complexity
-* Interoperability
-* Extensibility
-* Observability
-* ...
-
-# OAuth 2.x
-
-OAuth is for Authorization.
-
-# OAuth 2.x - Protocol Flow
-
-```plaintext
- +--------+ +---------------+
- | |--(A)- Authorization Request ->| Resource |
- | | | Owner |
- | |<-(B)-- Authorization Grant ---| |
- | | +---------------+
- | |
- | | +---------------+
- | |--(C)-- Authorization Grant -->| Authorization |
- | Client | | Server |
- | |<-(D)----- Access Token -------| |
- | | +---------------+
- | |
- | | +---------------+
- | |--(E)----- Access Token ------>| Resource |
- | | | Server |
- | |<-(F)--- Protected Resource ---| |
- +--------+ +---------------+
-```
-
-https://datatracker.ietf.org/doc/html/rfc6749#section-1.2
-
-# OAuth 2.x - Protocol Endpoints
-
-The authorization process utilizes two authorization server endpoints (HTTP resources):
-
-- Authorization endpoint - used by the client to obtain authorization from the resource owner via user-agent redirection.
-- Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication.
-
-https://datatracker.ietf.org/doc/html/rfc6749#section-3
-
-# OAuth 2.x - Authorization Grants
-
-* Authorization Code: `authorization_code`
-* JWT Bearer: `urn:ietf:params:oauth:grant-type:jwt-bearer`
-* Refresh Token: `refresh_token`
-* SAML Assertion: `urn:ietf:params:oauth:grant-type:saml2-bearer`
-
-# OAuth 2.x - Authorization Code Grant Protocol Flow
-
-```plaintext
- +----------+
- | Resource |
- | Owner |
- | |
- +----------+
- ^
- |
- (B)
- +----|-----+ Client Identifier +---------------+
- | -+----(A)-- & Redirection URI ---->| |
- | User- | | Authorization |
- | Agent -+----(B)-- User authenticates --->| Server |
- | | | |
- | -+----(C)-- Authorization Code ---<| |
- +-|----|---+ +---------------+
- | | ^ v
- (A) (C) | |
- | | | |
- ^ v | |
- +---------+ | |
- | |>---(D)-- Authorization Code ---------' |
- | Client | & Redirection URI |
- | | |
- | |<---(E)----- Access Token -------------------'
- +---------+ (w/ Optional Refresh Token)
-```
-
-# OAuth 2.x - Implicit Grant (not a recommendation)
-
-```plaintext
- +--------------------+
- | Resource Owner |
- +--------------------+
- ^
- (B)
- +----|-----+ Client Identifier +---------------+
- | +----(A)-- & Redirection URI --->| Authorization |
- | User- | | Server |
- | Agent -|----(B)-- User authenticates -->| |
- | |<---(C)--- Redirection URI ----<+---------------+
- | | with Access Token
- | | +---------------+
- | |----(D)--- Redirection URI ---->| Web-Hosted |
- | | without Fragment | Client |
- | | | Resource |
- | (F) |<---(E)------- Script ---------<+---------------+
- +-|--------+
- (A) (G) Access Token
- ^ v
- +---------+
- | Client |
- +---------+
-```
-
-# OAuth 2.x - Refresh Token Grant Protocol Flow
-
-```plaintext
- +--------+ +---------------+
- | |--(A)------- Authorization Grant --------->| |
- | | | |
- | |<-(B)----------- Access Token -------------| |
- | | & Refresh Token | |
- | | | |
- | | +----------+ | |
- | |--(C)---- Access Token ---->| | | |
- | | | | | |
- | |<-(D)- Protected Resource --| Resource | | Authorization |
- | Client | | Server | | Server |
- | |--(E)---- Access Token ---->| | | |
- | | | | | |
- | |<-(F)- Invalid Token Error -| | | |
- | | +----------+ | |
- | | | |
- | |--(G)----------- Refresh Token ----------->| |
- | | | |
- | |<-(H)----------- Access Token -------------| |
- +--------+ & Optional Refresh Token +---------------+
-```
-
-# OpenID Connect (OIDC)
-
-OIDC adds Authn to OAuth.
-
-# OIDC - Protocol Flow
-
-OIDC = Authn + OAuth
-
-```plaintext
-+--------+ +--------+
-| | | |
-| |---------(1) AuthN Request-------->| |
-| | | |
-| | +--------+ | |
-| | | | | |
-| | | End- |<--(2) AuthN & AuthZ-->| |
-| | | User | | |
-| RP | | | | OP |
-| | +--------+ | |
-| | | |
-| |<--------(3) AuthN Response--------| |
-| | | |
-| |---------(4) UserInfo Request----->| |
-| | | |
-| |<--------(5) UserInfo Response-----| |
-| | | |
-+--------+ +--------+
-```
-
-https://openid.net/specs/openid-connect-core-1_0.html#Overview
-
-# WLIF
-
-TODO:: Add a protocol flow diagram
-
-* https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation#how-it-works
-* https://docs.google.com/document/d/1XyuQXuUJE0kGC2jqy_vaLPGxAFjzMvJWOS74QoP7UA8/
-
-# Primitives
-
-We need:
-
-* PKI: Certificate Authority generate and sign intermediate certs
-* OAuth 2.x Authorization Server
-* OIDC Provider (OP)
diff --git a/doc/share/authz/ZANZIBAR.md b/doc/share/authz/ZANZIBAR.md
deleted file mode 100644
index fc49ab2d..00000000
--- a/doc/share/authz/ZANZIBAR.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Zanzibar
-
-Zanzibar is a planet-scale distributed ACL storage and evaluation system.
-Zanzibar's data model supports permissions, users, groups, and inheritance as
-found in the above systems. [1][1]
-
-Zanzibar servers delegate checks and reads to each other based on consistent
-hashing. Both the caller and the callee sides of the delegated operations cache
-the results to prevent hot spots. Zanzibar handles 22 million internal RPCs per
-second. In-memory caching handles approximately 200 million lookups per second
-at peak.
-
-Clients include:
-
-* Google Calendar
-* Google Cloud
-* Google Drive
-* Google Maps
-* Google Photos
-* YouTube
-
-Lessons learned
-
-* Access control patterns vary widely
-* Freshness requirements are often but not always loose. (i.e. moderate staleness during ACL evaluation is okay)
-* Performance optimizations
- * Request hedging is key to reducing tail latency. (Search issues 10s-100s of authz checks to serve a single set of search results.)
- * Hot-spot mitigation is critical for high availability: some workloads create hot spots in ACL data that can overwhelm database servers.
- * Performance isolation is indispensible to protect against misbehaving clients. (e.g. new feature launch that is popular. Unpredicatable usage patterns.)
-
-Roles are similar to Zanzibar relations. Roles can inherit from each other and
-imply permissions. Clients have implemented RBAC policies on top of Zanzibar's
-namespace configuration.
-
-Most IAM systems offer:
-
-* assigning users to roles or groups
-* domain-specific policy languages
-* API to edit ACLs.
-
-These systems have a communit unified ACL storage and and RPC-based API.
-
-It evaluates deeply or widely nested group membership with Leopard, a
-specialized index for efficient computation of set operations with snapshot
-consistency.
-
-## See Also
-
-* [1][1]
-
-[1]: https://storage.googleapis.com/gweb-research2023-media/pubtools/5068.pdf
diff --git a/doc/share/authz/todo/001_ldap.md b/doc/share/authz/todo/001_ldap.md
deleted file mode 100644
index 408cc771..00000000
--- a/doc/share/authz/todo/001_ldap.md
+++ /dev/null
@@ -1,19 +0,0 @@
-As an `Owner`, I want to `control group membership via LDAP`, so that `I can manage users in my company using my existing LDAP server`.
-
-# SYNOPSIS
-
-An external LDAP server should be able to synchronize data to the IdP.
-
-# DESCRIPTION
-
-# SEE ALSO
-
-* [ ] TBD
-
-# Tasks
-
-* [ ] TBD
-
-# Acceptance Criteria
-
-* [ ] TBD
diff --git a/doc/share/authz/todo/002_hierarchical_membership.md b/doc/share/authz/todo/002_hierarchical_membership.md
deleted file mode 100644
index 224eed7a..00000000
--- a/doc/share/authz/todo/002_hierarchical_membership.md
+++ /dev/null
@@ -1,19 +0,0 @@
-As an `Owner`, I want to `manage group membership`, so that `I can manage users in my company`.
-
-# SYNOPSIS
-
-Owners of an Organization can create group hierarchies and manage memberships to those groups.
-
-# DESCRIPTION
-
-# SEE ALSO
-
-* [ ] TBD
-
-# Tasks
-
-* [ ] TBD
-
-# Acceptance Criteria
-
-* [ ] TBD
diff --git a/doc/share/authz/todo/003_workload_identity_federation.md b/doc/share/authz/todo/003_workload_identity_federation.md
deleted file mode 100644
index a93353a7..00000000
--- a/doc/share/authz/todo/003_workload_identity_federation.md
+++ /dev/null
@@ -1,21 +0,0 @@
-As an `Operator`, I want to `integrate multicloud workloads`, so that `I can operate multiple clouds include on-premises`.
-
-# SYNOPSIS
-
-I have no idea what workload identity federation is but it sounds like a neat
-way to federate authn to an external/central identity provider to interop
-between multiple clouds.
-
-# DESCRIPTION
-
-# SEE ALSO
-
-* https://cloud.google.com/iam/docs/workload-identity-federation
-
-# Tasks
-
-* [ ] TBD
-
-# Acceptance Criteria
-
-* [ ] TBD
diff --git a/doc/share/authz/todo/004_acme_protocol.md b/doc/share/authz/todo/004_acme_protocol.md
deleted file mode 100644
index 93628f77..00000000
--- a/doc/share/authz/todo/004_acme_protocol.md
+++ /dev/null
@@ -1,69 +0,0 @@
-As an `Operator`, I want to `use the ACME protocol`, so that `I have a standards based way to manage PKI`.
-
-# SYNOPSIS
-
-Use the ACME protocol to generate TLS PKI.
-
-# DESCRIPTION
-
-Below is an example startup configuration for using the ACME protocol in golang
-and distributing the key material using file storage. The file storage should be
-replaced with a distributed blob storage that is locked down. This also uses
-the `STEPPATH` environment variable to access an internal root certificate
-authority.
-
-```golang
-func WithAcmeTLS(ctx context.Context, directoryURL string, cacheDir string) cfg.Option {
- storageFor := func(config *cfg.Config) certmagic.Storage {
- return &certmagic.FileStorage{Path: cacheDir}
- }
- return func(config *cfg.Config) {
- host := os.Getenv("HOST")
- tls := srv.NewTLS(ctx, host, storageFor(config), []certmagic.ACMEIssuer{
- {
- Agreed: true,
- CA: directoryURL,
- DisableHTTPChallenge: true,
- Email: "everyone@example.com",
- TestCA: directoryURL,
- TrustedRoots: newCertPool(),
- AltTLSALPNPort: bindingPort(),
- },
- })
- config.TLS = x.Must(tls.Config())
- }
-}
-
-func newCertPool() *x509.CertPool {
- certPool := x.Must(x509.SystemCertPool())
- certPool.AddCert(func() *x509.Certificate {
- block, _ := pem.Decode(x.Must(ioutil.ReadFile(
- filepath.Join(os.ExpandEnv("$STEPPATH"), "/certs/root_ca.crt"),
- )))
- return x.Must(x509.ParseCertificate(block.Bytes))
- }())
- return certPool
-}
-
-func bindingPort() int {
- parts := strings.SplitN(os.Getenv("BIND_ADDR"), ":", 2)
- bindPort, err := strconv.Atoi(parts[1])
- if err != nil {
- bindPort = 0
- }
- return bindPort
-}
-```
-
-# SEE ALSO
-
-* [RFC-8555](https://datatracker.ietf.org/doc/html/rfc8555)
-* [$STEPPATH](https://smallstep.com/docs/step-cli/reference/path/#examples)
-
-# Tasks
-
-* [ ] TBD
-
-# Acceptance Criteria
-
-* [ ] TBD
diff --git a/doc/share/authz/todo/005_open_pubkey.md b/doc/share/authz/todo/005_open_pubkey.md
deleted file mode 100644
index 92b0b7a8..00000000
--- a/doc/share/authz/todo/005_open_pubkey.md
+++ /dev/null
@@ -1,20 +0,0 @@
-As an `Owner`, I want to `enable ssh access via open pubkey`, so that `have a standard based approach to connect over SSH`.
-
-# SYNOPSIS
-
-Research OpenPubKey to see how it operates on top of OIDC to provide ephemeral
-SSH keys for temporary access.
-
-# DESCRIPTION
-
-# SEE ALSO
-
-* https://docs.bastionzero.com/openpubkey-ssh
-
-# Tasks
-
-* [ ] TBD
-
-# Acceptance Criteria
-
-* [ ] TBD
diff --git a/doc/share/authz/todo/006_zero_knowledge_proof.md b/doc/share/authz/todo/006_zero_knowledge_proof.md
deleted file mode 100644
index eb3984e9..00000000
--- a/doc/share/authz/todo/006_zero_knowledge_proof.md
+++ /dev/null
@@ -1,17 +0,0 @@
-As an `Developer`, I want to `understand what a zero knowledge proof is`, so that `I can understand how to be considerate of privacy`.
-
-# SYNOPSIS
-
-# DESCRIPTION
-
-# SEE ALSO
-
-* https://dl.acm.org/doi/pdf/10.1145/3708622.3708634
-
-# Tasks
-
-* [ ] TBD
-
-# Acceptance Criteria
-
-* [ ] TBD
generated by cgit v1.2.3 (git 2.39.1) at 2026-02-02 06:02:42 +0000