Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Effective ACR discovery #244

Merged
merged 37 commits into from
Aug 18, 2021
Merged
Show file tree
Hide file tree
Changes from 10 commits
Commits
Show all changes
37 commits
Select commit Hold shift + click to select a range
51e0a64
Effective ACR discovery
matthieubosquet Jul 27, 2021
98444d9
Update proposals/evaluation/uc-0-effective-acr.md
matthieubosquet Jul 27, 2021
f234ea8
Update proposals/evaluation/uc-0-effective-acr.md
matthieubosquet Jul 27, 2021
b3b02c2
Update proposals/evaluation/uc-0-effective-acr.md
matthieubosquet Jul 27, 2021
5b7b0a0
Update proposals/evaluation/uc-0-effective-acr.md
matthieubosquet Jul 27, 2021
9fcbb06
Update proposals/evaluation/uc-0-effective-acr.md
matthieubosquet Jul 27, 2021
561d052
Update proposals/evaluation/uc-0-effective-acr.md
matthieubosquet Jul 29, 2021
64b2efa
Update proposals/evaluation/uc-0-effective-acr.md
matthieubosquet Jul 29, 2021
893dc36
illustrate in full a WAC search for the ACL
bblfish Aug 11, 2021
54114f0
formatting
bblfish Aug 11, 2021
fc42c54
WAC+Trig
bblfish Aug 11, 2021
58f5882
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
c976ac5
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
aff3e23
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
458feef
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
59b6ee0
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
b0af854
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
eb03196
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
b964c53
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
d491ea0
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
1265368
Apply suggestions from code review
bblfish Aug 12, 2021
12d5ef9
Apply suggestions from code review
bblfish Aug 12, 2021
542ee62
WAC+:imports
bblfish Aug 12, 2021
ed04363
wac + acl=control
bblfish Aug 12, 2021
4610f80
fix important typo in rel=control exmaple
bblfish Aug 12, 2021
42e999d
minor fixes
bblfish Aug 12, 2021
e2b4f81
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
6799dd9
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
0ebddb3
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
7bd0597
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
d3d5c7f
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
05bd3fc
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
8050dba
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
d744e61
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
6f97adf
Update proposals/evaluation/uc-0-effective-acr.md
bblfish Aug 12, 2021
94d0547
Formula for nbr of req to find WAC effective ACR
bblfish Aug 12, 2021
627ace9
Apply suggestions from code review
bblfish Aug 13, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
165 changes: 165 additions & 0 deletions proposals/evaluation/uc-0-effective-acr.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,165 @@
# Effective Access Control Resource Discovery Use Cases

This is part 0 of the [implementation specific use cases comparison](./use-cases.md).

The "effective access control resource" (ACR) of a resource R, is the resource that contains the rules that will be used by the server to determine access to R.


## 1. Discovering a resource's effective access control

A Solid client that wants to decide which credentials to present to access a resource or determine if it can edit the ACR, needs to discover the effective ACR of the resource in question.

### Setup

We have the following hierarchy of resources:

```turtle
</default.acr>
</foo/bar/baz/x>
</foo/bar/baz/x.acr>
```

### Universal effective ACR discovery

Both WAC and ACP follow an `acl` link header in the response to a resource `R` in order find the Access Control Rules.
bblfish marked this conversation as resolved.
Show resolved Hide resolved
(The name "acl" for the type of such a link [is being discussed](https://github.com/solid/authorization-panel/issues/228).)


We can start both our examples with the client making a `GET` request on `/foo/bar/baz/x` which returns either of the following responses:

A. The response is successful but the client wants to then edit the access control rules
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
200 Ok
Link: </foo/bar/baz/x.acr>; rel="acl"
Link: <.>; rev="http://www.w3.org/ns/ldp#contains"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is rev ldp contains in any spec? Any implementation? Why is this part of the evaluation?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the WAC spec says

WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading towards the root container).

For ldp the way to find the container is by following the reverse of ldp:contains.
As I understand you don't specify how to find the container. So I don't see any other way for ldp of finding the parent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right in that it is unspecified, and that can be a reasonable way for LDP clients to find the container of a resource.

Content-Length: 2042
Content-Type: ...

...
```
B. The response is unsuccessful and the client wants to find out how to authenticate to gain access:
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
401 Unauthorized
Link: </foo/bar/baz/x.acr>; rel="acl"
Link: <.>; rev="http://www.w3.org/ns/ldp#contains"
```

The second `Link`, with relation type `ldp:contains`, is needed for WAC.

### ACP

In ACP, every resource has exactly 1 effective access control resource directly associated with it, and every access control resource directly governs access over itself and exactly one other resource.
bblfish marked this conversation as resolved.
Show resolved Hide resolved

In ACP, access control statements can be spread over several resources; that is, an access control resource can reference other resources.

In ACP, the access control system in place (that is, ACP, as opposed to WAC, for example) is indicated via a `Link` header of `rel="type"` `<http://www.w3.org/ns/solid/acp#AccessControlResource>` in HTTP response to a request for an ACR.

On receiving the `404` with the `Link` header given in our example, the client can make a request on `/foo/bar/baz/x.acr` if it wants to look at the Access Control Rules.
bblfish marked this conversation as resolved.
Show resolved Hide resolved
As in ACP all resources have an associated ACR, the resource <`/foo/bar/baz/x.acr>` should return a description of the sets of agents that can have access to the resource.
bblfish marked this conversation as resolved.
Show resolved Hide resolved
This may include links to rules published elsewhere.

### WAC

In WAC, the effective ACR of a resource might be the ACR of a parent container of the resource.
Copy link
Member

@bblfish bblfish Aug 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the client's point of view the only thing that matters should be the Link: <....acl>; rel="acl"> relation in the header.
The text about the effective ACL process (see my other comment) is aimed at the server I think.
But that means that the Link: </.acl>, rel="acl"> pointing to the default only allows the client to edit the default ACL document, as the client cannot just create ACL resources by guessing them.

So that means that: a server that allows the client to also edit acls for a resource must have 2 Link: headers: one for the default and that could be created with a PUT, in order to override the default. I think @csarven agreed with that in the last meeting.

Copy link
Member

@csarven csarven Aug 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't recall saying that. I probably said that (UN)LINK methods can be used or extensions can be introduced to do those things - as mentioned in the current WAC ED.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I thought we had come to the conclusion that having two acl links could solve the problem. But it is not in the meeting notes.

Does the spec explicitly state that one cannot have two link headers?

Anway, so if I understand you correctly, the right way to do things is for the acl link header to point to the non-existent acl for that resource, and if the client gets a 404 Page not found then it should follow the links down the hierarchy container by container to find the default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a full description of what needs to be done in WAC with a default three levels deep in this commit. 893dc36

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Superb, thank you Henry.


In WAC, ACRs are called ACLs (Access Control Lists).

WAC's [Effective ACL Resource](https://solid.github.io/web-access-control-spec/#effective-acl-resource) discovery is described in [the WAC spec](https://solid.github.io/web-access-control-spec/) as follows:

> ##### Effective ACL Resource Algorithm
> To determine the effective ACL resource of a resource, perform the following steps. Returns string (the URI of an ACL Resource).
>
> 1. Let resource be the resource.
> 2. Let aclResource be the ACL resource of resource.
> 3. If resource has an associated aclResource with a representation, return aclResource.
> 4. Otherwise, repeat the steps using the container resource of resource.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the algorithm for determining the ACL of a resource in the spec is relevant to the client.
In the previous wiki version of the spec on which the current spec is based it was stated quite clearly that one should not try to guess.
So I think that text is only aimed at the server, to allow the server to determine which ACL to add to the header. Am I right @csarven ?
btw. I think that means the text "To determine the effective ACL..." should be: "For a server to determine..." the effective ACL of a resource...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it is aimed at any anything that wants to determine the ACL of a resource, including servers, clients..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous version of the document that was the official one just a little over a month ago, stated that

It is considered an anti-pattern for a client to perform those steps, however. A client may discover and load a document's individual resource (for example, for the purposes of editing its permissions). If such a resource does not exist, a client SHOULD NOT search for, or interact with, the inherited ACLs from an upstream container.

Also the algorithm given for finding the container is very vague, because you are trying to specify WAC without assuming LDP, which would make finding the container a lot simpler.

So should we instead write up an example where the client has to try to guess its way back up the hierarchy to find the default ACL? I guess we can make our lives a bit simpler to ourselves if we also have a
Link: <.>; rev="http://www.w3.org/ns/ldp#contains"> on the resource, so that the client can find the default.

Which do you prefer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous document did say that but we also had an issue on solid/specification#106 to change that. WAC ED's #effective-acl-resource addressed that issue.

As for WAC without LDP's containment.. that makes the spec more flexible and combined with other specs. Servers implementing LDP/Solid can already work with it.

Just as with ACP, the client can follow the `Link: <...acr>; rel="acl"` relation to find out the rules of access.
But then we have to cases with WAC:
bblfish marked this conversation as resolved.
Show resolved Hide resolved

1. the ACR exists and returns the rules
2. the ACR returns a `404 Not Found`

In (1) everything follows like with ACP above.
In (2) the client then needs to start the recursive process of looking for the effective ACR.
bblfish marked this conversation as resolved.
Show resolved Hide resolved
We will detail (2) next.

1. First the client is lucky enough to be shown the reverse `ldp:contains` relation, so it can do a HEAD on that to find its `ACL`.
```HTTP
HEAD /foo/bar/baz/ HTTP/1.1
```
and with luck the server will respond
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
200 Ok
Link: </foo/bar/baz/.acr>; rel="acl"
Link: </foo/bar/>; rev="http://www.w3.org/ns/ldp#contains"
```
The client can then continue with
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
GET /foo/bar/baz/.acr HTTP/1.1
```
to which the server will also return
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
404 Not Found
```
as the resource does not yet exist.
bblfish marked this conversation as resolved.
Show resolved Hide resolved

2. As a result the client will need to look up one level in the hierarchy to search for the effective ACR
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
HEAD /foo/bar/ HTTP/1.1
```
and with luck the server will respond
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
200 Ok
Link: </foo/bar/.acr>; rel="acl"
Link: </foo/>; rev="http://www.w3.org/ns/ldp#contains"
```
The client can then continue with
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
GET /foo/bar/baz/.acr HTTP/1.1
```
to which the server will also return
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
404 Not Found
```
as the resource does not yet exist.
bblfish marked this conversation as resolved.
Show resolved Hide resolved

3. As a result the client will need to look up one level in the hierarchy to search for the effective ACR
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
HEAD /foo/ HTTP/1.1
```
and with luck the server will respond
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
200 Ok
Link: </foo/.acr>; rel="acl"
Link: </>; rev="http://www.w3.org/ns/ldp#contains"
```
The client can then continue with
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
GET /foo/.acr HTTP/1.1
```
to which the server will also return
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
404 Not Found
```
as the resource does not yet exist.
bblfish marked this conversation as resolved.
Show resolved Hide resolved

4. As a result the client will need to look up one level in the hierarchy to search for the effective ACR
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
HEAD / HTTP/1.1
```
and with luck the server will respond
bblfish marked this conversation as resolved.
Show resolved Hide resolved

```HTTP
200 Ok
Link: </.acr>; rel="acl"
```
The client can then continue with
bblfish marked this conversation as resolved.
Show resolved Hide resolved
```HTTP
GET /foo/.acr HTTP/1.1
```
to which the server will finally return the content.
bblfish marked this conversation as resolved.
Show resolved Hide resolved

## See also

- [Access Control Resource discovery](https://github.com/solid/authorization-panel/issues/228)
1 change: 1 addition & 0 deletions proposals/evaluation/use-cases.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@ Within the use cases, the following namespace prefix bindings are used:
It is assumed in the example solutions to use cases for both WAC and ACP that
the effective access control resource is represented.

0. [Effective Access Control Resource Discovery](./uc-0-effective-acr.md)
1. [Resource Access](./uc-1-resource-access.md)
2. [Collection Access](#)
3. [Access Inheritance Use Cases](./uc-3-inheritance.md)
Expand Down