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
< allow | deny > (AccessMode1, …), AND
< allow | deny > (AccessMode2, …), AND
…

An Access Policy statement contains:

Policy Components

Descriptions

Access Rules Expressions

Specifies the conditions under which Access Policy applies.

The Access Rules expressions use allOf(<rules>), anyOf(<rules>), and noneOf(<rules>) operators. The expressions must evaluate to true for the policy to apply.

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:

  • https://pod.example.com/AlliGator/profile/card#me

FriendsRule

Agent is one of the following agent WebIDs:

  • https://pod.example.org/AlliGator/profile/card#me

  • https://pod.example.com/Emu123/profile/card#me

  • https://pod.example.net/MissySippy/profile/card#me

CompanyGroupRule

Agent is in the group MyCompany, where the group MyCompany has the following members:

  • https://pod.example.com/MollyMoose/profile/card#me

  • https://pod.example.net/MissySippy/profile/card#me

  • https://pod.example.net/ChiKadee/profile/card#me

CollegeGroupRule

Agent is in the group MyCollege, where the group MyCollege has the following members:

  • https://pod.example.com/AlliGator/profile/card#me

  • https://pod.example.com/Emu123/profile/card#me

  • https://pod.example.net/Iggy98/profile/card#me

  • https://pod.example.com/MollyMoose/profile/card#me

ClientAppRule

Client application has one of the following identifiers:

  • https://myApprovedApp1.example.com/myappid

  • https://myApprovedApp2.example.net/myappid

allOf, anyOf, noneOf Expressions#

A policy specifies its rules in allOf(), anyOf(), and noneOf() operator expressions.

allOf(<rules>)

Evaluates to true if all of its listed rules evaluate to true; i.e., a logical AND of its listed rules.

anyOf(<rules>)

Evaluates to true if any of its listed rules evaluate to true; i.e., a logical OR of its listed rules.

noneOf(<rules>)

Evaluates to true if none of its listed rules evaluate to true; i.e., a logical NOT of its listed rules.

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 FriendsRule NOR 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) AND

    • the agent does not satisfy the CompanyGroupRule.

  • anyOf(FriendRule, CompanyGroupRule), allOf(ClientAppRule)

    Evaluates to true if:

    • the agent satisfies any of the (FriendsRule OR CompanyGroupRule) AND

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

allow(Read)

Allows Read access.

The expression grants view permissions to those agents that meet the policy’s Access Rules expressions.

allow(Read, Write)

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.

deny(Write)

Denies Write access.

The expression revokes the add, update, and delete permissions from those agents that meet the policy’s Access Rules expressions.

deny(Read,Write)

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:

allow(Read); deny(Write)

Allows Read access AND denies Write access.

ESS evaluates the deny expressions after the allow expressions, removing the deny Access Modes from its list of granted Access Modes. As such, ESS:

  • First, grants the Read access to those agents that meet the policy’s Access Rules expressions, AND

  • Then, revokes the Write mode from those agents.

The two expressions result in granting Read access (view permissions).

deny(Append); allow(Read,Append)

Allows Read and Append access AND denies Append access.

ESS evaluates the deny expressions after the allow expressions, removing the deny Access Modes from its list of granted Access Modes. As such, ESS:

  • First, grants the Read and Append modes to those agents that meet the policy’s Access Rules expressions, AND

  • Then, revokes the Append mode from those agents.

The two expressions result in granting Read access (view permissions).

deny(Write); allow(Read,Append)

Allows Read and Append access AND denies Write access.

ESS evaluates the deny expressions after the allow expressions, removing the deny Access Modes from its list of granted Access Modes. As such, ESS:

  • First, grants the Read and Append modes to those agents that meet the policy’s Access Rules expressions, AND

  • Then, revokes the Write mode from those agents. Since the Write mode has not been granted to the agents, the deny is a no-op.

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:

  • https://pod.example.com/AlliGator/profile/card#me

FriendsRule

Agent is one of the following agent WebIDs:

  • https://pod.example.org/AlliGator/profile/card#me

  • https://pod.example.com/Emu123/profile/card#me

  • https://pod.example.net/MissySippy/profile/card#me

CompanyGroupRule

Agent is in the group MyCompany, where the group MyCompany has the following members:

  • https://pod.example.com/MollyMoose/profile/card#me

  • https://pod.example.net/MissySippy/profile/card#me

  • https://pod.example.net/ChiKadee/profile/card#me

CollegeGroupRule

Agent is in the group MyCollege, where the group MyCollege has the following members:

  • https://pod.example.com/AlliGator/profile/card#me

  • https://pod.example.com/Emu123/profile/card#me

  • https://pod.example.net/Iggy98/profile/card#me

  • https://pod.example.com/MollyMoose/profile/card#me

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 the noneOf(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 apply

That 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.