Access Control Policy (ACP)#
ESS uses Access Control Policy (ACP) to manage access to Pod resources. 1 With ACP, Pod owners can define Policies that determine access for their Pod’s resources.
Access Control Resource#
Each Pod resource has an associated Access Control Resource (ACR) that contains the policies that determine access to the Pod resource.
The lifecycle of the ACR is bound to the lifecycle of the Pod resource; that is:
When creating a resource, ESS creates a corresponding ACR.
When deleting a resource, ESS deletes the corresponding ACR.
ESS’ Authorization Service hosts the ACRs.
If a resource has no Policies that apply to it, the resource is inaccessible. However, the Pod owner and other agents with access to modify the resource’s ACR can add new policies to provide access to the resource.
Note
Having read/write/append access to policies for a resource (i.e., write to the resource’s ACR) is distinct from having access to read/write/append the resource itself.
Policies#
Policies determine access for Pod resources. A policy statement consists of:
Matcher statements that specify conditions that must be satisfied for the Policy to take effect.
Access mode statements that specify which access modes are allowed and/or denied to the agent(s) satisfying the Matcher statements.
- If
< allOf | anyOf > (Matcher(s)) evaluates to true, AND< allOf | anyOf | noneOf > (Matcher(s)) evaluates to true, AND…- Then
<allow (AccessMode(s)) | deny (AccessMode(s)) | allow (AccessMode(s)) AND deny (AccessMode(s)) >
Important
The noneOf()
expression excludes matches from the allOf
and
anyOf
expressions; i.e., you can use the noneOf
expression
to refine the allOf
and anyOf
matches.
Because the noneOf()
expression acts as a
secondary/supplementary filter to the allOf
and anyOf
expressions, a policy statement with only a noneOf(<matchers>)
condition cannot be satisfied.
Matcher Statements#
< allOf | anyOf > (Matcher(s)) evaluate to true, AND< allOf | anyOf | noneOf > (Matcher(s)) evaluates to true, AND…
Matchers#
Matchers specify the conditions under which the Access Policy applies.
ESS supports the following types of Matchers:
Agent Matchers |
To match agents by specific WebID(s).
To match any authenticated agent.
To match any agent.
|
Client Application Matchers |
To match by specific Client Identifier(s).
To match any client application.
|
Issuer Matchers |
To match by specific Identity Provider(s).
To match any Identity Provider.
|
Verifiable Credentials Matchers |
To match by specific Verifiable Credential(s). |
allOf
, anyOf
, noneOf
Operators#
A policy specifies its matchers in allOf()
, anyOf()
, and
noneOf()
operator expressions.
|
Evaluates to true if all of its listed matchers evaluate to true. |
|
Evaluates to true if any of its listed matchers evaluate to true. |
|
Evaluates to true if none of its listed matchers evaluate to true. |
Important
The noneOf()
expression excludes matches from the
allOf
and anyOf
expressions; i.e., you can use the
noneOf
expression to refine the allOf
and anyOf
matches.
Because the noneOf()
expression acts as a
secondary/supplementary filter to the allOf
and anyOf
expressions, a policy statement with only a
noneOf(<matchers>)
condition cannot be satisfied.
Access Mode Statements#
<allow (AccessMode(s)) | deny (AccessMode(s)) | allow (AccessMode(s)) AND deny (AccessMode(s)) >
Access Modes#
Access Modes describe the permissions that can be granted or denied. The available modes are:
Access Mode |
Description |
---|---|
|
Permission to view/retrieve a resource. See also CRUD Operations and Access Modes. |
|
Permission to create a resource, update the content of a resource, and delete a resource: Tip
See also CRUD Operations and Access Modes. |
|
Permission to add content to a resource:
See also CRUD Operations and Access Modes. |
allow
, deny
Expressions#
A policy statement specifies its access modes in allow(Access
Modes)
or deny(Access Modes)
expressions:
The
allow
expression specifies the access modes to be granted.The
deny
expression specifies the access modes to be denied.
An agent is granted an access mode for a resource if:
The agent satisfies a policy that allows the access mode for the resource, and
The agent does not satisfy any policy that denies that access mode for the resource.
For example:
If a resource only has a single policy that allows
Read
andWrite
for an agent, the the agent is grantedRead
andWrite
for the resource.If a resource has:
A policy that allows
Read
andWrite
for an agent, andA policy that denies
Write
for the same agent,
Then, the agent is granted
Read
access for the resource.
If no “allow access” policy is satisfied for a resource, then that resource is inaccessible to the agent. That is, an unsatisfied “deny access” policy does not confer access. For example,
If a resource has defined only a single policy that denies
Read
and the policy is unsatisfied by an agent, that agent still does not have any access to that resource.
CRUD Operations and Access Modes#
This section summarizes the relationship between Create/Read/Update/Delete (CRUD) operations and the access modes.
To create a resource, the user requires either an Append
or
Write
access.
Note
The creation operation creates the resource (be it container, RDF resource, non-RDF resource) and updates the content of the parent container with the new resource’s metadata.
Resource |
Description |
---|---|
Either For example, to create
|
|
Either For example, to create
|
|
Either For example, to create
|
For read operations, the user requires Read
access.
Resource |
Description |
---|---|
Reading a container (which stores metadata about the
resources contained within the container) allows a client
to discover what resources are contained inside the
container and their resource type (i.e., analogous to an
|
|
For example, if a resource has as its URL
|
|
For example, if a non-RDF resource has as its URL
|
For update operations, the user requires Append
or Write
access, depending on the specific update operation.
Resource |
Description |
---|---|
Resource |
Description |
To add resources to the Container, see the To delete resources from the Container, see the |
|
|
|
For example, if the non-RDF resource has as its URL
|
For delete operations, the user requires Write
access.
Resource |
Description |
---|---|
For example, to delete
Tip To delete a container, the container must be empty. |
|
To delete an RDF resource , For example, to delete
|
|
To delete a non-RDF resource, For example, to delete
|
- 1
The Access Control Policy (ACP) is in Draft status. Features based on draft specifications are subject to change.