Authorization/Access Control

An authorization system determines whether an agent has access to perform a given action on a particular resource.

ACP

ESS uses Access Control Policy (ACP) to define the policies that determine access to Pod’s resources.

If

< allOf | anyOf > (Matchers) evaluates to true, AND

< allOf | anyOf | noneOf > (Matchers) evaluates to true, AND

...

Then

<allow (AccessModes) | deny (AccessModes) | allow (AccessModes) AND deny (AccessModes) >

For more information, see Access Control Policy (ACP)

Access Control Mechanisms

ESS supports:

  • Identity-Based Access , where access to Pod resources is based on agents’ identity, and optionally, the identity of their clients. To use identity based access, the resource must have ACPs that specify the Agents’ WebIDs (and, optionally, Client IDs).

  • Access Grants, where access to Pod resources can be requested and granted. To use Access Grants, the resource must have ACP that enables the use of Access Grants.

Authorization Services

To support authorization, ESS provides the following services:

Authorization and Clients

ESS supports the the use of Client IDs in client allow lists and access policies.

Client Allow Lists

Operators can use Client IDs in the following allow lists:

Client Matchers

Client IDs can be used in Client Matcher statements in Access Control Policy (ACP) policies.

For example, if client allow list configuration for the initial policy is set, ESS creates default ACP policies of the form:

If allOf(AgentMatcher and ClientMatcher) evaluates to true, Then allow (Read and Write).

Note

  • ESS does not support the use of dynamically registered Client ID values in client allow lists and access policies.

  • Inrupt does not provide support for ESS servers running Web Access Control (WAC) in Production.

Last updated