Release Notes#
Installation and Upgrades#
Starting in version 2.0, ESS provides:
inrupt-kustomizer
to install or upgrade ESS.Various Kustomize overlays that can act as the base configuration for your deployment.
In addition, improved quality health checks allow for a more robust rolling deploy.
For more information, see:
Pods and WebIDs#
Separate Storage Services and WebID Services#
Starting in 2.0, ESS replaces the LDP service (available in earlier ESS versions) with separate:
With this change, Pods and WebIDs are created independently of each other, and WebIDs are no longer hosted on the Pods. This change allows for multiple Pods per WebID, prevents users from locking themselves out of their Pods, and allows users to obtain their WebID or Pods from alternative providers.
As part of this change:
When ESS provisions a new Pod, it creates the Pod with the URL:
https://storage.{ESS Domain}/{Unique Pod Identifier}/
When ESS creates a new WebID, ESS creates a WebID of the form:
https://id.{ESS DOMAIN}/{username}
See also:
Security#
Access Control Mechanisms#
ESS 2.0 supports:
Identity-Based Access Policies, where access to Pod resources is determined by specific access policies based on agents’ identity, and optionally, the identity of their clients.
Access Requests and Grants, where access to Pod resources can be requested and granted (or denied).
To support these mechanisms, ESS also adds UMA Service. This service allows clients to exchange a token or access grant in one format for an access token.
In earlier versions, ESS only supports identity-based access.
For more information, see Authorization/Access Control.
Access Control Policy (ACP) Changes#
In line with the latest Editor’s Draft of Access Control Policy, ACP changes include:
ACR (Access Control Resource) is hosted on the Authorization Service. In earlier version, ACRs were located in the Pod.
Policies must exist within ACRs. In earlier version, Policies could be stored in a non-ACR resource and just referred to in an ACR.
Matchers replaces
Rules
. Along with the naming change,Matchers
require a match in order for the Policy to apply.The
noneOf(<Matchers>)
expression excludes matches from theallOf(<Matchers>)
andanyOf(<Matchers>)
expressions; that is,noneOf(<Matchers>)
expression acts as a secondary/supplementary filter to theallOf
andanyOf
expressionsRemoves match by
Group
(whereGroup
is identified by its URI/IRI). Instead, specify a matcher with a list of agents.Matchers must be attached to a Policy.
For more information, see Access Control Policy (ACP).
Access Control Client Allow List#
Starting in version 2.0, ESS adds a new configuration option
INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST
that determines which
applications can interact with Access Control Resource; that is, which
applications can read and write access control policies for a resource.
UMA 2.0 Support#
Starting in 2.0, ESS provides a User Managed Access Grant 2.0 (UMA) service. This service allows clients to exchange a token or credential in one format for an access token.
For more information, see UMA Service.
Access Request/Grant Support#
Starting in version 2.0, ESS supports authorization mechanism based on Access Requests and Grants. With authorization mechanism based on Access Requests and Grants:
Agents can request access to resources from the resource owners.
The resource owners can either grant or deny the access request.
If the access request is granted, the requesting agent can use the access grant to access the requested resource.
For more details, see:
Services#
New Services#
New Service |
Notes |
---|---|
To support auditing activities from ESS services. In earlier ESS version, instead of a separate service, auditing is handled as a named category of Quarkus logging. For more information on the service, see Auditing Service and Auditing. |
|
To manage Pod creation. The service also creates the extended profiles. In earlier ESS version, LDP service handled WebID provisioning as well as Pod provisioning and hosting. For more information on the service, see Pod Provisioning Service. |
|
To host the created Pods. The service is also responsible for reading and writing the resources stored in the Pod. In earlier ESS version, LDP service handled WebID provisioning as well as Pod provisioning and hosting. For more information on the service, see Pod Storage Service. |
|
To host a default application that acts as the starting point for ESS users. The start application handles the signup or login flow. As part of this flow, the application provisions the user with a WebID and a Pod. For more information on the service, see Start Service. See also custom start application. |
|
To support User Managed Access (UMA) Grant 2.0 authorization flow. This service allows clients to exchange a token or credential in one format for an access token that can be used to interact with a Pod resource. For more information, see UMA Service. |
|
To support authorization based on access requests and grants. The new service:
For more information, see Access Grant Service. |
|
To create WebIDs and host their corresponding Profile documents. In earlier ESS version, LDP service handled WebID provisioning as well as Pod provisioning and hosting. For more information, see Separate Storage Services and WebID Services. |
Changed Services#
Changed Service |
Notes |
---|---|
In ESS 2.0, Authorization Service changes include:
For more information, see |
|
In ESS 2.0, Solid OIDC Broker Service changes include:
For more information, see: |
|
In ESS 2.0, Quad Pattern Fragment (QPF) service changes include:
For more information, see Quad Pattern Fragment (QPF) service. |
Removed Services#
Removed Service |
Notes |
---|---|
LDP Service |
ESS replaces the LDP service with separate: See also: |
Search Access Service |
ESS 2.0 no longer provides search See Query Service instead. |