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

ACL Inheritance Algorithm problem #257

Closed
bblfish opened this issue Apr 30, 2021 · 2 comments
Closed

ACL Inheritance Algorithm problem #257

bblfish opened this issue Apr 30, 2021 · 2 comments

Comments

@bblfish
Copy link
Contributor

bblfish commented Apr 30, 2021

The WAC spec has the following text:

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.

This seems on the whole unjustified.

  1. Why is it an anti-pattern? This is not explained. If the rule for the server is that access control rules must be applied in this way, then why can the client not follow the same pattern itself? (we can assume there is a Link relation to a container for example)
  2. How is a client to know what the Access Control Rules for a resource is, if the access control Rule is not linked from the primary resource?

If the client cannot find out what the access control rule is, then either the client looses privacy by being forced to try out different credentials (see Minimal Credential Disclosure use case) or not knowing how to authenticate it may not be able to access a resource it has the right to access.

If access to a access-control resource is not ok, then one option would be to return all the access control information relevant to a resource in the returned 401. But that comes with its own problems, such as what mime-type to send the answer back in (e.g. on a 401 on a picture or video), or how this can play correctly with servers that wish to return a human readable response. Furthermore returning all the information in the response body means that one is not able to structure access levels to different parts of the Access-Control Rules, which is possible with linked-to resources. A simple example is given in the ACRs on ACRs comment which shows how one can have parts of an access control rule visible and others hidden.

Having linked access control rules allows one to have hierarchies of access to the rules. One ACR may require one prove that one is a Citizen of a certain country, the next that one is part of an institution (a bank, the army, ...) and the third level could state that one needs to prove the grade that one has in that organization. (say for security classified documents, where the fact that a document is secured should only be known to trusted members)

The limitations is currently unwarranted. If there are reasons as to why it is "bad practice" it should be discussed and clarified.

A better way to do this would be instead to have Access Control Resources link to the access control resources they inherit from explicitly. This follows the principle of client/server symmetry: if the server has rules on how to follow links, the client must be able to follow those same rules.

@csarven
Copy link
Member

csarven commented Apr 30, 2021

See #106 . Before diving deep into that, I suggest checking with the current state of the Protocol and .. upcoming WAC. Or just hang on for a bit.. :)

@csarven
Copy link
Member

csarven commented Jul 8, 2021

Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ . See #effective-acl-resource-algorithm that can be used by clients and servers.

@csarven csarven closed this as completed Jul 8, 2021
@csarven csarven added this to the ~First Public Working Draft milestone Jul 8, 2021
@csarven csarven moved this to Done in Specification Sep 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

3 participants