Access Control Policy (ACP)
ESS uses Access Control Policy (ACP) to manage access to Pod resources. With ACP, Pod owners can define Policies that determine access for their Pod’s resources.
Policies
Policies determine access for Pod resources. A policy 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)](acp.md#acp-matcher)) evaluates to true, AND
< allOf | anyOf | noneOf > ([Matcher(s)](acp.md#acp-matcher)) evaluates to true, AND
…
Then< allow ( [AccessMode(s)](acp.md#acp-access-modes) ) | deny ( [AccessMode(s)](acp.md#acp-access-modes) ) | allow ( [AccessMode(s)](acp.md#acp-access-modes) ) AND deny ( [AccessMode(s)](acp.md#acp-access-modes) ) >
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)](acp.md#acp-matcher)) evaluate to true, AND
< allOf | anyOf | noneOf > ([Matcher(s)](acp.md#acp-matcher)) evaluates to true, AND
…Matchers
Matchers specify the conditions under which the Access Policy applies.
ESS supports matching:
Agents
To match agents by specific WebID(s).
To match any authenticated agent.
To match any agent.
Clients
To match by specific Client ID(s).
To match any client application.
See also Authorization and Clients
Verifiable Credentials
To match by Verifiable Credential(s) type; e.g., match VC type
http://www.w3.org/ns/solid/vc#SolidAccessGrant.
allOf, anyOf, noneOf Operators
A policy specifies its matchers in allOf() , anyOf() , and noneOf() operator expressions.
allOf(<matchers>)
Evaluates to true if all of its listed matchers evaluate to true.
anyOf(<matchers>)
Evaluates to true if any of its listed matchers evaluate to true.
noneOf(<matchers>)
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
Access Modes
Access Modes describe the permissions that can be granted or denied. The available modes are:
Read
Permission to view/retrieve a resource as well as to subscribe to notifications for the resource. See also CRUD Operations and Access Modes.
Write
Permission to create a resource, update the content of a resource, and delete a resource.
Tip:
* To create a resource, you must have Write access on both the resource and the resource’s container.
* To delete a resource, you must have Write access on both the resource and the resource’s container.
See also CRUD Operations and Access Modes.
Append
Permission to add content to a resource.
If a resource is a container (analogous to a folder in a file system), the Append permission on the resource allows agents to add new resources (container, RDF resource, non-RDF resource) to the container.
If a resource is an RDF resource, the Append permission on a resource allows agents to add statements to the 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
allowexpression specifies the access modes to be granted.The
denyexpression 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
ReadandWritefor an agent, the agent is grantedReadandWritefor the resource.If a resource has:
A policy that allows
ReadandWritefor an agent, andA policy that denies
Writefor the same agent,Then, the agent is granted
Readaccess 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
Readand 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 required access modes.
To create a resource, the user requires either an Append or Write access.
Either Append or Write access on the parent container (under which the new container is to be created) allows agents to create a new container. For example, to create https://storage..../parentcontainer/newContainer/, either an Append or a Write access on https://storage..../parentcontainer/ allows agents to create https://storage..../parentcontainer/newContainer/.
Either Append or Write access on the parent container (under which the new resource is to be created) allows agents to create a RDF resource. For example, to create https://storage..../parentcontainer/newResource/, either an Append or a Write access on https://storage..../parentcontainer/ allows agents to create https://storage..../parentcontainer/newResource.
Either Append or Write access on the parent container (under which the new resource is to be created) allows agents to create a new non-RDF resource. For example, to create https://storage..../parentcontainer/foo.jpg, Append or Write access on https://storage..../parentcontainer/ allows agents to create https://storage..../parentcontainer/foo.jpg.
For read operations , the user requires Read access.
Read access on the target container (analogous to a folder in a file system) allows agents to read/retrieve the container as a resource (not the resource(s) under the container). That is, Read access only affects read operation on the container itself. 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 ls on a folder in a file system).
Read access on the RDF resource allows agents to read/retrieve the resource (regardless of the access on the parent container). For example, if a resource has as its URL https://storage..../container/ResourceToRead, to read/retrieve this resource: The user must have Read access on https://storage..../container/ResourceToRead. The user’s access on https://storage..../container/ is immaterial.
Read access on a non-RDF resource allows agents to read/retrieve the resource (regardless of Read access on the container). For example, if a non-RDF resource has as its URL https://storage..../container/foo.jpg, to read/retrieve this resource: The user must have Read access on https://storage..../container/foo.jpg. The user’s access on https://storage..../container/ is immaterial.
For update operations, the user requires Append or Write access, depending on the specific update operation.
To add resources to the Container, see the Create tab. To delete resources from the Container, see the Delete tab.
Either Append or Write access on an RDF resource allows agents to add content (statements) to the resource. Write access on an RDF resource allows agents to delete content (statements) from the resource. Write access on an RDF resource allows agents to modify existing content (statements) in the resource.
Write access on the target resource allows agents to overwrite/replace the resource (regardless of the access on the parent container). For example, if the non-RDF resource has as its URL https://storage..../container/foo.jpg, to overwrite this resource: The user must have Write access on https://storage..../container/foo.jpg. The user’s access on https://storage..../container/ is immaterial.
For delete operations, the user requires Write access.
Write access on both the parent container and the target container allows agents to delete the target container. For example, to delete https://storage..../parentcontainer/containerToDelete/, Write access on both https://storage..../parentcontainer/ and https://storage..../parentcontainer/containerToDelete/ allows agents to delete https://storage..../parentcontainer/containerToDelete/.
To delete an RDF resource, Write access on both the parent container and the target resource allows agents to delete the target resource. For example, to delete https://storage..../parentcontainer/resourceToDelete/, Write access on both https://storage..../parentcontainer/ and https://storage..../parentcontainer/resourceToDelete allows agents to delete https://storage..../parentcontainer/resourceToDelete.
To delete a non-RDF resource, Write access on both the parent container and the target resource allows agents to delete the target resource. For example, to delete https://storage..../parentcontainer/foo.jpg, Write access on both https://storage..../parentcontainer/ and https://storage..../parentcontainer/foo.jpg allows agents to delete https://storage..../parentcontainer/foo.jpg.
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.
If a resource has no Policies that apply to it, the resource is inaccessible. However, the Pod owner can add new policies to provide access to the resource.
Member Policies
If a resource is a Container, you can also specify Member Policies in the Container’s ACR. Member Policies will be inherited by the Container’s children/descendants.
Access to ACRs
ESS’ Authorization Service hosts the ACRs. The Authorization Service ‘s INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST determines which clients can write policies to ACRs.
In version 2.0, ESS also uses the values in INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST as part of the initial ACP policies that determine the read/write/append access to the Pod and its resource.
Starting in 2.1, ESS uses the values in INRUPT_AUTHORIZATION_DEFAULT_ACR_CLIENT_ID_ALLOW_LIST if set. If unset, ESS uses the values in INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST (same as it did in version 2.0).
For details, see Initial ACP Policies .
Initial ACP Policies
When a Pod is created, like any other Pod resource, an Access Control Resource is also created for the Pod Root. The ACR is initialized with the default ACP policies for the Pod Owner and for Access Grant enablement:
Initial Pod Owner policies give the Pod Owner read and write access to the Pod. These policies also specify a client matcher as well if the Authorization service’s configuration for the initial client allow list is set:
INRUPT_AUTHORIZATION_DEFAULT_ACR_CLIENT_ID_ALLOW_LISTor if that is unset,
Using the value of the Pod owner’s WebID and an initial client allow list, ESS creates the initial policies of the form:
Specifically, ESS creates:
Policy 1 for the Pod Root:If the agent matches the Pod owner’s WebID , and if the client application’s Client ID has a match in the initial client allow list, allow Read and Write access.
Policy 2 for the Pod Root’s Initial Member Policies:If the agent matches the Pod owner’s WebID , and if the client application’s Client ID has a match in the initial client allow list, allow Read and Write access.
For more information on a Container’s Member Policies, see Member Policies .
If the initial client allow list is empty (when creating the policy), ESS uses the value of the Pod owner’s WebID to create initial policies of the form:
Specifically, ESS creates:
Policy 1 for the Pod Root:If the agent matches the Pod owner’s WebID , allow Read and Write access.
Policy 2 for the Pod Root’s Initial Member Policies:If the agent matches the Pod owner’s WebID , allow Read and Write access.
For more information on a Container’s Member Policies, see Member Policies .
Disambiguation
Both Authorization Service and Pod Storage Service have a INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST setting.
Only the Authorization Service setting affects which clients are allowed. The Pod Storage Service is for Discovery purposes only.
Initial Access Grant Enablement policies allow the use of Access Grants that grant read/write/append access to the Pod resources. New in Version 2.2
Specifically, ESS creates:
Policy 3 for the Pod Root:If a presented VC matches the specified type, allow its use for Read, Write, and Append access.
Policy 4 for the Pod Root’s Initial Member Policies:If a presented VC matches the specified type, allow its use for
Read, Write, and Append access.
See alsoINRUPT_AUTHORIZATION_DEFAULT_ACR_ACCESS_GRANTS_ALLOWED_MODES.
Important
The policies only enable the use of Access Grants for the allowed access modes. To determine the access for an agent using an access grant, ESS uses the intersection of:
The allowed access specified by the policy, and
The granted access specified in the Access Grant (for the resource specified in the Access Grant).
ESS’ ACP is based on an earlier version of the Access Control Policy (ACP) Specification .
Inrupt does not provide support for ESS servers running Web Access Control (WAC) in Production.
Examples
Create Policy to Match Agents and Clients
The following example sets up an app-friends-policy that allow Read and Write access to any Agent that satisfies the match-app-friends Matcher conditions; namely, Agents whose WebID matches one of the specified WebIDs and is using an application whose Client Identifier matches the specified Client IDs. When verifying against a policy that specifies a Client Application Matcher, the user must be logged in. A Policy that specifies a Client Application Matcher but no Agent Matcher does not match any agent.
Details
In particular, the example uses:
acp_ess_2.getSolidDatasetWithAcr to retrieve the SolidDataset with its ACR.
To specify policies for files with other structures (such as .pdf or .jpeg files), use acp_ess_2.getFileWithAcr instead.
acp_ess_2.createResourceMatcherFor to initialize the Matcher that will be used by the policy.
When saved, the Matcher URL will be
{ACR URL}#match-app-friends.acp_ess_2.addAgent to specify the WebID of the agent(s) to match:
acp_ess_2.addClient to specify the Client ID of the application(s) to match.
acp_ess_2.setResourceMatcher to store the new matcher definition to the ACR:
acp_ess_2.createResourcePolicyFor to initialize the policy:
When saved, the policy URL will be
{ACR URL}#app-friends-policy.acp_ess_2.addAllOfMatcherUrl to add the matcher to the policy.
acp_ess_2.setAllowModes to specify that the policy allows
ReadandWritemodes:acp_ess_2.addPolicyUrl to apply the new policy to the resource:
acp_ess_2.setResourcePolicy to store the new policy definition to the ACR:
acp_ess_2.saveAcrFor to save the modified ACR.
Make a Resource Public: Create Public Policy for a Resource
The following example uses the ACP-specific APIs to set up a public-policy that allows Read access to the public (i.e., everyone) for a resource.
Details
In particular, the example uses:
acp_ess_2.getSolidDatasetWithAcr to retrieve the SolidDataset (the SolidDataset can be a Container) with its ACR.
To specify policies for files with other structures (such as .pdf or .jpeg files), use acp_ess_2.getFileWithAcr instead.
acp_ess_2.createResourceMatcherFor to initialize the Matcher that will be used by the policy.
When saved, the Matcher URL will be
{ACR URL}#match-public.acp_ess_2.setPublic to specify that the matcher is a Public matcher; i.e., matches everyone.
acp_ess_2.setResourceMatcher to store the matcher definition to the ACR:
acp_ess_2.createResourcePolicyFor to initialize the policy for the Resource:
When saved, the policy URL will be
{ACR URL}#public-policy.acp_ess_2.addAllOfMatcherUrl to add the matcher to the policy.
acp_ess_2.setAllowModes to specify the access modes for the policy:
acp_ess_2.addPolicyUrl to apply the new policy to the resource:
acp_ess_2.setResourcePolicy to store the new policy definition to the ACR:
acp_ess_2.saveAcrFor to save the modified ACR.
View Policies and Matchers for a Resource
The following example uses the ACP-specific APIs to view the ACP policies for a resource.
Details
In particular, the example uses:
acp_ess_2.getSolidDatasetWithAcr to retrieve the SolidDataset (the SolidDataset can be a Container) with its ACR.
To specify policies for files with other structures (such as .pdf or .jpeg files), use acp_ess_2.getFileWithAcr instead.
getSolidDataset with getLinkedAcrUrl to retrieve the ACR.
Once you retrieve the ACR as a SolidDataset, you can use solidDatasetAsTurtle to format ACR as Turtle.
acp_ess_2.getResourcePolicyAll to get the policies from the resource’s ACR.
To view a specific policy, you can use acp_ess_2.getResourcePolicy:
acp_ess_2.getResourceMatcherAll to get all matchers from the resource’s ACR.
To view a specific matcher, you can use acp_ess_2.getResourceMatcher:
Delete Existing Policy for a Resource
The following example deletes an existing Policy for a resource.
Details
In particular, the example uses:
acp_ess_2.getSolidDatasetWithAcr to retrieve the SolidDataset (the SolidDataset can be a Container) with its ACR.
To specify policies for files with other structures (such as .pdf or .jpeg files), use acp_ess_2.getFileWithAcr instead.
acp_ess_2.removeResourcePolicy to delete the Policy definition from the ACR:
acp_ess_2.removeResourcePolicy can also accept the Policy URL or the Policy itself instead of the Policy name.
acp_ess_2.saveAcrFor to save the modified ACR.
Modify Existing Matcher for a Resource
The following example continues from an earlier example. Specifically, the example modifies the match-app-friends created in Create Policy to Match Agents and Clients to remove one of the Agents from the match list.
Tip
To view existing Matchers for a resource, see View Policies and Matchers for a Resource.
Details
In particular, the example uses:
acp_ess_2.getSolidDatasetWithAcr to retrieve the SolidDataset (the SolidDataset can be a Container) with its ACR.
To specify policies for files with other structures (such as .pdf or .jpeg files), use acp_ess_2.getFileWithAcr instead.
acp_ess_2.getResourceMatcher to get the Matcher from the resource’s ACR.
The
match-app-friendswas created in an earlier example, Create Policy to Match Agents and Clients.Tip
To view existing Matchers for a resource, see View Policies and Matchers for a Resource.
acp_ess_2.removeAgent to remove an Agent’s WebID from the list of the Matcher’s WebIDs to match.
acp_ess_2.setResourceMatcher to update the Matcher definition in the ACR:
acp_ess_2.saveAcrFor to save the modified ACR.
Modify Existing Policy for a Resource
The following example continues from an earlier example. Specifically, the example modifies the app-friends-policy created in Create Policy to Match Agents and Client.
Details
In particular, the example uses:
acp_ess_2.getSolidDatasetWithAcr to retrieve the SolidDataset (the SolidDataset can be a Container) with its ACR.
To specify policies for files with other structures (such as .pdf or .jpeg files), use acp_ess_2.getFileWithAcr instead.
acp_ess_2.getResourcePolicy to get the Policy from the resource’s ACR. The
app-friends-policywas created in an earlier example, Create Policy to Match Agents and Clients.Tip
To view existing Policies for a resource, see View Policies and Matchers for a Resource.
acp_ess_2.setAllowModes to update the Write access mode for the Policy. The other Access Modes for this Policy remain unchanged.
For additional Policy functions, see the API documentation.
acp_ess_2.setResourcePolicy to update the Policy definition in the ACR:
acp_ess_2.saveAcrFor to save the modified ACR.
Last updated