Authorization/Access Control#
An authorization system determines whether someone has access to perform a given action on a particular resource.
ESS uses Access Control Policies (ACP) to manage authorization to resources stored in Solid Pods. ACP is being proposed for inclusion in the Solid specifications.
With ACP, Access Policies determine the access for a Pod’s resource. The Pod Owner, by default, can create/modify the Access Policies for any of the Pod’s resources. The Pod Owner can also grant access to others to specify the Access Policies for a resource. Each Pod has a single Pod Owner.
Access Policy#
Access Policies define an agent’s access to a resource.
An Access Policy allows and/or denies the specified Access Modes based on the evaluation of its Access Rules. That is,
- If
< allOf | anyOf | noneOf > (RuleA1, RuleA2, …) evaluate to true, AND< allOf | anyOf | noneOf > (RuleB1, RuleB2, …) evaluates to true, AND…- Then
An Access Policy statement contains:
Policy Components |
Descriptions |
---|---|
Access Rules Expressions |
Specifies the conditions under which Access Policy applies. The Access Rules expressions use For more information, see Access Rules. |
Access Modes Specifications |
Indicates which Access Modes to apply and/or which Access Modes to deny if the access rules expressions evaluate to true. For more information, see Access Modes. |
Access Rules#
Access Rules specify the conditions under which the Access Policy applies.
Access Rule Conditions#
Access Rules can specify the following conditions:
Agent is in a specified list of WebIDs.
Agent is a member of a specified group.
Agent has authenticated.
Agent has not authenticated.
Client application is in a list of Client Identifiers.
Client application can be any app.
For example:
Example Rule |
Example Rule Definition |
---|---|
RoommateRule |
Agent is one of the following agent WebIDs:
|
FriendsRule |
Agent is one of the following agent WebIDs:
|
CompanyGroupRule |
Agent is in the group MyCompany, where the group MyCompany has the following members:
|
CollegeGroupRule |
Agent is in the group MyCollege, where the group MyCollege has the following members:
|
ClientAppRule |
Client application has one of the following identifiers:
|
allOf
, anyOf
, noneOf
Expressions#
A policy specifies its rules in allOf()
, anyOf()
, and
noneOf()
operator expressions.
|
Evaluates to true if all of its listed rules evaluate to true;
i.e., a logical |
|
Evaluates to true if any of its listed rules evaluate to true;
i.e., a logical |
|
Evaluates to true if none of its listed rules evaluate to true;
i.e., a logical |
For example:
allOf(FriendsRule, CollegeGroupRule)
Evaluates to true if the agent satisfies all the listed rules (FriendsRule
AND
CollegeGroupRule).
anyOf(CompanyGroupRule, CollegeGroupRule)
Evaluates to true if the agent satisfies any of the listed rules (CompanyGroupRule
OR
CollegeGroupRule).
noneOf(FriendRule, CompanyGroupRule)
Evaluates to true if the agent does not satisfy the listed rules (i.e.,
Neither
FriendsRuleNOR
CompanyGroupRule).
A policy can include multiple allOf()
, anyOf()
, and
noneOf()
expressions. ESS uses a logical AND
to join the
multiple expressions. For example:
allOf(RoommateRule), anyOf(FriendsRule, CollegeGroupRule), noneOf(CompanyGroupRule)
Evaluates to true if:
the agent satisfies the RoommateRule AND
the agent satisfies any of the (FriendsRule
OR
CollegeGroupRule) ANDthe agent does not satisfy the CompanyGroupRule.
anyOf(FriendRule, CompanyGroupRule), allOf(ClientAppRule)
Evaluates to true if:
the agent satisfies any of the (FriendsRule
OR
CompanyGroupRule) ANDthe agent is using a client application that satisfies the ClientAppRule.
Access Modes#
Access Modes describe the type of permissions to a resource. The following Access Modes are available:
Access Mode |
Description |
---|---|
Read |
Permission to view a Resource. |
Write |
Permission to add, update, and delete a Resource. |
Append |
Permission to add a new Resource or add data to an existing Resource. |
allow
, deny
Expressions#
A policy statement specifies its access modes in allow(Access
Modes)
or deny(Access Modes)
expressions:
The
allow
expression grants the Access Mode.The
deny
expression revokes the Access Mode.
For example:
|
Allows Read access. The expression grants view permissions to those agents that meet the policy’s Access Rules expressions. |
|
Allows Read and Write access. The expression grants view, add, update, and delete permissions to those agents that meet the policy’s Access Rules expressions. |
|
Denies Write access. The expression revokes the add, update, and delete permissions from those agents that meet the policy’s Access Rules expressions. |
|
Denies Read and Write access. The expression revokes view, add, update, and delete permissions from those agents that meet the policy’s Access Rules expressions. |
A policy statement can specify both allow
and deny
expressions.
When evaluation policy statements, ESS first evaluates all the
allow
expressions, maintaining a list of the granted Access Modes.
Then, ESS evaluates all the deny
expressions, removing the Access
Modes from its list of granted Access Modes. The remaining Access Modes
in the list determine the permissions.
For example:
|
Allows Read access AND denies Write access. ESS evaluates the
The two expressions result in granting Read access (view permissions). |
|
Allows Read and Append access AND denies Append access. ESS evaluates the
The two expressions result in granting Read access (view permissions). |
|
Allows Read and Append access AND denies Write access. ESS evaluates the
The two expressions result in granting Read access (view permissions) and Append access (add permissions). |
Evaluating Policies#
The Access Policies determine the agent’s access to a resource. A resource can have zero, one, or more Access Policies.
Resource with No Access Policy#
If a resource has zero Access Policies, the resource is inaccessible. However, the Pod owner and other agents with access to modify the resource’s policies can add new Access Policies to provide access to the resource.
Note
Having access to read/write Access Policies for a resource is distinct from having access to read/write/append the resource itself.
Resource with a One or More Access Policies#
If a resource has a single Access Policy, the policy determines the access to the resource.
If a resource has multiple Access Policies, ESS evaluates all the policies to determine the access to the resource. ESS first evaluates all the allow expressions, maintaining a list of the granted Access Modes. Then, ESS evaluates all the deny expressions, removing the Access Modes from its list of granted Access Modes. The remaining Access Modes in the list determine the permissions.
For example, if one policy grants Write to an agent, and another policy denies Append to the agent, the two policies evaluate to granting the agent Write access to the resource. Whereas, if one policy grants Read and Write to an agent, and another policy denies Write to the agent, the two policies evaluate to granting only the Read to the agent.
Example Access Policies#
For the following examples, assume the following rules:
Rule Name |
Rule Definition |
---|---|
RoommateRule |
Agent is one of the following agent WebIDs:
|
FriendsRule |
Agent is one of the following agent WebIDs:
|
CompanyGroupRule |
Agent is in the group MyCompany, where the group MyCompany has the following members:
|
CollegeGroupRule |
Agent is in the group MyCollege, where the group MyCollege has the following members:
|
Example 1#
The following policy statement refers to rules defined at the start of the Examples section.
Consider a resource that has the following Access Policy:
Access Policy
Policy |
Access Rule Expressions |
Access Mode Specification |
---|---|---|
Policy1: |
allOf(RoommateRule) |
allow(Read) |
- Policy Evaluation
Policy1 allows Read if RoommateRule (which specifies the user AlliGator) evaluates to true. That is:
For AlliGator
Policy1: Grants Read access (view permissions).
Example 2#
The following policy statements refer to rules defined at the start of the Examples section.
Consider a resource that has the following Access Policy:
Access Policy
Access Rule Expressions |
Access Mode Specification |
|
---|---|---|
Policy1: |
anyOf(FriendsRule, CollegeGroupRule), noneOf(CompanyGroupRule) |
allow(Read); deny(Write) |
- Policy Evaluation
Policy1 allows Read and denies Write if:
Any of
FriendsRule (which specifies users AlliGator, Emu123, MissySippy)
OR
CollegeGroupRule (which specifies users AlliGator, Emu123, Iggy98, MollyMoose) evaluates to true,
AND
None of CompanyGroupRule (which specifies users MollyMoose, MissySippy, ChiKadee) evaluates to true; i.e., the user is not MollyMoose, MissySippy, nor ChiKadee.
Although MissySippy and MollyMoose meet the
anyOf
(FriendsRule, CollegeGroupRule), they fail thenoneOf
(CompanyGroupRule). As such, the policy does not apply to these users.ESS first evaluates all the allow expressions first, maintaining a list of the granted Access Modes. Then, ESS evaluates all the deny expressions, removing the deny Access Modes from its list of granted Access Modes.
That is,
For AlliGator
Policy1: Grants Read Access and denies Write access.
That is, AlliGator has Read Access (view permissions).
For Emu123
Policy1: Grants Read Access and denies Write access.
That is, Emu123 has Read Access (view permissions).
For Iggy98
Policy1: Grants view and revokes add, update, and delete permissions.
That is, Iggy98 has Read Access (view permissions).
Example 3#
The following policy statements refer to rules defined at the start of the Examples section.
Consider a resource that has the following two Access Policies:
Access Policy
Access Rule Expressions |
Access Mode Specification |
|
---|---|---|
Policy1: |
allOf(FriendsRule) |
allow(Read,Append) |
Policy2: |
allOf(CollegeGroupRule) |
allow(Read); deny(Append) |
- Policy Evaluation
Policy1 grants Read and Append if FriendsRule (which specifies users AlliGator, Emu123, MissySippy) evaluates to true.
Policy2 grants Read and denies Append if CollegeGroupRule (which specifies users AlliGator, Emu123, Iggy98, MollyMoose) evaluates to true.
ESS first evaluates all the allow expressions first, maintaining a list of the granted Access Modes. Then, ESS evaluates all the deny expressions, removing the permissions from its list of granted Access Modes.
That is:
For AlliGator
Policy1: Grants Read mode (view permissions) and Append mode (add permissions).Policy2: Grants Read mode (view permissions) and denies Append mode (add permissions).That is, AlliGator has Read access (view permissions).
For Emu123
Policy1: Grants Read mode (view permissions) and Append mode (add permissions).Policy2: Grants Read mode (view permissions) and denies Append mode (add permissions).That is, Emu123 has Read access (view permissions).
For MissySippy
Policy1: Grants Read mode (view permissions) and Append mode (add permissions).Policy2: Does not applyThat is, MissySippy has Read access (view permissions) and Append access (add permissions)
For Iggy98
Policy1: Does not apply.Policy2: Grants Read mode (view permissions) and denies Append mode (add permissions).That is, Iggy98 has Read access (view permissions).
For MollyMoose
Policy1: Does not apply.Policy2: Grants Read mode (view permissions) and denies Append mode (add permissions).That is, MollyMoose has Read access (view permissions).
Additional Information#
ESS also supports Web Access Control (WAC). However, you can not use both ACP and WAC on the same Pod.
Note
ESS supports Web Access Control (WAC) for spec compatibility purposes. Inrupt does not provide support for ESS servers running WAC in Production.