search

solid / web-access-control-spec

Web Access Control (WAC)
https://solid.github.io/web-access-control-spec/
MIT License
121 stars 25 forks source link

Client identification #81

Open csarven opened 3 years ago

csarven commented 3 years ago

Clients making HTTP requests on behalf of agents (social entities) may need to be given different set of access privileges than the agents.

Considerations:

timbl commented 3 years ago

When a person with one webid does something using an authenticated client app, then they both need to have access. Both in this case have a webid. Seems logical to use acl:agent to connect to both.

timbl commented 3 years ago

("delegation"? No, when you are talking about a bot, a free running system with its own webid, not an app, then delegation is when I say that I want to confer some rights which I have to the bot, say, or another person)

elf-pavlik commented 3 years ago

I believe this use case may help with illustrating case where user delegates subset of their access rights to an application they use to exercise their access rights, while following the principle of least privilege. https://solid.github.io/authorization-panel/authorization-ucr/#uc-client-constraints

TallTed commented 3 years ago

"Clients" appear to be, and should likely be referred to as, "agents (software)" or "software agents" when used alongside or with "agents (social entities)" or "social agents" (which appear to be "users", which are commonly discussed alongside "clients" and "servers").

This will likely help to simplify some things (though it may complicate others) when you get deeply into delegation and such, as I would think there's less "special" handling needed for a "delegate client" (which is a new class that largely duplicates agent) than for a "delegate agent" (which is a slightly specialized case of the agent class).

matthieubosquet commented 3 years ago

Specific predicate for the client (eg. acl:client as possibly a subPropertyOf acl:agent) vs. reuse acl:agent since the object ie. the WebID that's changing.

I don't think the same predicate can be used for identifying agent and client in a WAC Authorization.

A server will receive a request performed by an agent x using a client y. The WAC engine will need to be able to discriminate between the two since I assume the aim here will be to further restrict access depending on which client an agent uses, that is, if agent x has read/write/control and the client y they're using has only read, then read should be the only granted permission.

Is my assumption correct?

Maybe it is worth considering that it might imply a significant departure from WAC's current "grant permission" on first match approach.

Maybe I'm naively thinking the client would be defined alongside agents in an Authorization and actually what is meant here would be a completely separate mechanism for filtering access permissions altogether. I'd be curious to understand what would be envisaged if that were the case, maybe an AuthorizationFilter?

elf-pavlik commented 3 years ago

A server will receive a request performed by an agent x using a client y.

That's the assumption in Solid-OIDC, Resource Server (Solid Storage) should have both identifiers available for any request. The only exception is access by navigating the web browser directly to the resource, in which case the Solid Storage itself acts as OAuth client.

Grant Negotiation and Authorization Protocol: 1.1. Roles uses following terminology:

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

Maybe I'm naively thinking the client would be defined alongside agents in an Authorization and actually what is meant here would be a completely separate mechanism for filtering access permissions altogether.

I would like to emphasize that UC linked above has title 2.5.2. Limiting application access while not acting as resource controller.

acoburn commented 3 years ago

The GNAP terminology is very useful here, even if one is not using the GNAP protocol.

I am :+1: on any mechanism that is able to distinguish between an App (i.e. "Resource Client") and a User (i.e. "Requesting Party")

matthieubosquet commented 3 years ago

I would like to emphasize that UC linked above has title 2.5.2. Limiting application access while not acting as resource controller.

I also think it would be useful and make sense to be able to filter resource access permissions based on Resource Client globally. The natural fit for expressing such restrictions in my opinion would be the WebID. But then, that is a completely new mechanism, so I wouldn't jump on it.

Additionally, I think it will be quite prevalent to restrict resource access permissions based on Resource Client for specific resources over which one is acting as the resource controller. Almost no app should be unrestricted to access my data and I'd be keen to see what such access permissions filters might look like too.

elf-pavlik commented 3 years ago

The natural fit for expressing such restrictions in my opinion would be the WebID. But then, that is a completely new mechanism, so I wouldn't jump on it.

Do you refer to https://github.com/solid/web-access-control-spec#other-ideas-about-specifying-trusted-apps ?

This approach has some privacy issues, person may no want to make public what authorization they give to which app. We have prior conversation on alternative approaches. One would involve out of band notification to relevant parties where app access restrictions have to be enforced. Another alternative would just require client application to present claim (credential / capability) proving authorization that user granted it. I believe this conversation should continue elsewhere, just hinting here that we have prior discussions around those requirements.

jeff-zucker commented 3 years ago

The term "client" has multiple possible meanings. What makes sense to me is sub properties of acl:agent:

  acl:user [a foaf:Agent, foaf:Person]
  acl:app [a foaf:Agent, dc:Software; rdfs:comment "an OIDC Resource Client"]
  acl:group [a foaf:Agent, vcard:Group]
elf-pavlik commented 3 years ago

client is pretty established in OAuth2 and GNAP which aims to learn from OAuth2 experience.

jeff-zucker commented 3 years ago

And how many people who aren't familiar with those standards are going to know or remember the difference? Am I the agent or the client? And in this case, the client is an agent which adds an additional confusion.

elf-pavlik commented 3 years ago

In Interop spec we refer to Person or Organization as Social Agent and to clients as Applications. I think we should still map them to GNAP / OAuth2 terminology.

AJamesPhillips commented 3 years ago

@jeff-zucker your comment: https://github.com/solid/web-access-control-spec/issues/81#issuecomment-917212377 reminds me of hueniverse 's insightful and ardent critique of OAuth2: https://web.archive.org/web/20160304014802/http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ https://web.archive.org/web/20160306192304/http://hueniverse.com/2012/07/30/on-leaving-oauth/ https://vimeo.com/52882780 https://web.archive.org/web/20160304014608/http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-an-oauth-replacement/

woutermont commented 1 year ago

@csarven, do you now what the current status is of client-id in WAC, and how we can make this gain some progress?

tomhgmns commented 1 year ago

As we are implementing Solid Interop, we are running into the issue that there is no way to define by which application a social agent may do something with data.

In other words, this issue becomes very relevant...

@csarven can we bring this issue to the surface again by discussing it during a weekly community meeting?

csarven commented 1 year ago

Noted re surfacing. To help with the spec progress, as always, commitment to implement or adequate implementation experience works. I gather that's been the case here and elsewhere for some time now.

Edit: clarified the current definition.

The current definition of acl:agent:

acl:agent
  a rdf:Property ;
  rdfs:label "agent" ;
  rdfs:comment "A person or social entity to being given the right" ;
  rdfs:domain ac:Authorization ;
  rdfs:range foaf:Agent .

Something like acl:client rdfs:subPropertyOf acl:agent may be incorrect based on the rdfs:comment - contrary to my first comment - but would be allowed with respect to the rdfs:range value. As far as I know (read: anecdotal evidence) "agent" wasn't particularly limited to person/social entities but I'm not going to argue that here. We can however consider whether the definition of acl:agent needs to be improved, e.g., along the lines of the term "agent" (not to be conflated with acl:agent) that's currently used in the WAC spec:

<https://solidproject.org/TR/2021/wac-20210711#agent>
  a skos:definition "An agent is a person, social entity or software identified by a URI, e.g., a WebID denotes an agent [WEBID]."@en .

Updating acl:agent's comment with that definition may suffice (without introducing a new property acl:client) with respect to allowing Authorizations to take client identifier into account because #authorization-evaluation is generally about finding a matching graph, as demonstrated with ASK queries in the spec. So possible to have different Authorization graphs for a person and a client all meanwhile using acl:agent for both - if we broaden the definition of acl:agent. But let's come back to this.)

I would add that in the case of only using acl:agent, while each thing (person, social entity, or software) can describe itself, that information needs to be either repeated in the #acl-resource or one will have to dereference the URI. However, with acl:client, it is not necessary to look for additional information about the the thing.

Let's work through perhaps some obvious questions / assumptions. Using acl:client (or acl:agent) for the purpose of discussion:

bblfish commented 1 year ago

Note, with HTTP Sig working via a wallet or through an http proxy, the signatures can be thought of as coming I think directly from the user. Ie. the Solid Wallet (see now an nlnet project), being as it is a secure app, its signing of a header is no different than a browser using an X509 client certificate. In BAN Logic this would come down to the relation that the wallet speaksFor the user. Ie. Everything the Wallet says the User says too.

In the wallet setup, there is no need to limit clients in WAC rules. Instead, the wallet limits what it signs instead. The Wallet could itself have WAC rules as to what spaces a client can access. Just thinking about this quickly, here is an idea of the rules the Wallet could use to limit the banking app to Wells Fargo's web site.

<#bankAppRule> a wac:Authorization;
    wac:agent </apps/bankApp/Id#> ;
    wac:accessToClass [ allResourcesStartingWith <https://wellsfargo.com/> ]
    wac:mode wac:Read, wac:Write .
bblfish commented 1 year ago

@RubenVerborgh regarding identifying an app: you can identify an app with a WebId as I did in the WAC rules above. There </apps/bankApp/Id#> is meant to be the App Instance WebID. As the Wallet (Launcher App) launches the Banking App, it knows that the process it is communicating with is that app and by consulting its WAC rules the Wallet can decide when to sign the request headers.

On the "speaks for" relation see Abadi's Logic in Access Control tutorial notes from 2003. The speaks-for relation was initially developed as early as 1989 by Abadi, Needham and Mike Burrows in a famous paper. (Note Burrows was the author of the AltaVista search engine). (You can have the wallet sign every request btw, in which case it is approved by you, assuming your setup is correct of course)...

woutermont commented 1 year ago

@RubenVerborgh, I did not interpret this issue as being about identification of the client (Solid-OIDC already handles that). Rather, the question here i.m.o. is what happens after a client is authenticated: how can a system using WAC incorporate that identity information in access control rules?

woutermont commented 1 year ago

☝️ @csarven @elf-pavlik @justinwb I've given it a shot to implement my interpretation of this in the CSS

rosshorne commented 1 year ago

Hi all, I'm bumping this, since I think it wasn't resolved and is critical, as mentioned here: https://github.com/solid/solid-oidc/issues/221

Would it make sense to resolve this thread as an editorial decision in the Solid Protocol Spec itself?

Specifically, references to WAC should be dropped entirely from the Solid Protocol spec and ACP made normative. The property acp:client in the context graph is essential. Naming the client in ACP ensures that users (acp:agent) can use the same identity to log in to multiple apps (acp:client), without information intended for one app being compromised by another app. Not all apps can be trusted to the same degree.

The thread already reflects well this problem, but I didn't see action in the Solid Protocol spec. Officially removing WAC and making only ACP normative I see as the simplest solution. This has the added benefit of simplifying the Solid Protocol.

woutermont commented 1 year ago

While there hasn't been any engagement on WAC lately, it is reasonable that an update to the spec can resolve this. I did a prototype implementation of such a possible update in the CSS (https://github.com/CommunitySolidServer/CommunitySolidServer/pull/1537).

That being said, both WAC and ACP are not fit as access control mechanisms by themselves. Direct access to access control resources should be avoided. The use of WAC/ACP should be an implementation decision of authorization servers, rather than of resource servers. Solid protocol should i.m.o. include neither, and fully separate access control from resource management.

rosshorne commented 1 year ago

I see the update @woutermont links to above suggests extending WAC to address the problem. That's fine technically, but it just means that WAC converges more with ACP (as noted already in the comments in CSS). It would be cleaner to pick one or the other instead of having two convergent specs, and since WAC must evolve to cope with security, then ACP is a cleaner basis. It would be interesting to know if there are security arguments for evolving WAC v.s. dropping WAC and making only ACP normative.

Whether the status of WAC should be clarified in the Solid Protocol specification or whether references to WAC and ACP should be removed from there and clarified elsewhere, as @woutermont suggests, is an editorial decision. I don't have an opinion on where in the specification this edit should be made. The editors might have a view. However, it is a priority issue to resolve in one way or another, since the current spec permits data breaches by exploiting WAC or misusing ACP (think about all the fines being issued these days).

The action point here is: what editorial decision should be made regarding WAC.

Separately: The point made by @woutermont about the usage of WAC/ACP, e.g., public v.s. private access control, I can see multiple sides to. In some settings, it's better to assume the app knows the access control rules it should follow (perhaps because the pod follows a known policy in order for it to be used with a particular trusted app), so that a trusted app can connect to a pod without leaking unnecessary information about what the pod may be used for to attackers. In other scenarios, its better to make the access control rules public so that apps can follow their nose more so (I understand that this is currently how most implementations work, and is what @woutermont points to -- please correct me if you were pointing elsewhere @woutermont). However, this kind of problem may be addressed separately from the priority problem: that is, can we agree on dropping WAC to avoid data breaches due to WAC missing essential information provided by the ACP context graph.

woutermont commented 1 year ago

WAC will never fully align with ACP, since they are based on different views of security (basic permission vs basic denial). There has been a lot of words on this already (e.g. https://github.com/solid/specification/issues/447, https://github.com/solid/authorization-panel/issues/128). Advocates of either of them will likely never be persuaded to drop one in favor of the other. One way to go forward with both of them could be merge them together into a specification that would enable the basis (permissoin or denial) to be set freely somehow, though I am not really interested in exploring that personally.

Re public access control rules, it is just basic separation of concerns that authorization is managed by a different entity than resource management. No use case comes to mind that would benefit from that, which would not benefit equally or more from separated non-public management of access control rules by an authorization server (which can of course be hosted by the same provider as the resource server).

That being said, this issue is actually specifically about the absence of client identification in WAC. It might be better to raise your WAC-vs-ACP concern in a new, separate issue, or continue in https://github.com/solid/specification/issues/447.

bblfish commented 1 year ago

I wrote up in detail how clients can be Authorized using Web Access Control here. https://github.com/co-operating-systems/PhD/blob/main/UseCases/ClientAuth.md

Would be very happy for feedback. (updated ClientAuth.md at 13:39 CET)