Proposal: scope tags in WAC for fine-grain user control of app privilege #48
Comments
|
this is prototyped in my WebID Authorization Server for nginx. |
|
an an the second case can be exploited to enable a coarse allow/disallow for an app at a server by either giving the app |
|
Good stuff, couple of quick points:
|
no. this proposal is to address several points in several Issues (you can see three reverse references in the transcript above) both here and in other panels, as well as discussions on panel calls about problems with the current "trusted apps" scheme (and in particular how it doesn't solve the real problems of the user choosing what apps to use/trust, not the controller) and for attenuated app permission (although approaching that from the opposite direction).
there is nothing stopping people from using IRIs as tags (except consideration for the characters my implementation stringifies tag objects before performing matching, so one could say (with a useful result) the notion of arbitrary freeform tags and bidirectional wildcarding is borrowed from one aspect of AWS access control. applying wildcarding to IRIs is certainly possible, but you would want to design the vocabulary so that wildcarding could be applied effectively to achieve the user's intent. it might also start to get weird if (in some imagined vocabulary in use on some server) you wanted to express |
|
One can do this I think in a way that is more amenable to reasoning, and extension by using the Below I consider how one can use that general framework for the use cases that the proposal attempts to address. Let's take the use case of wanting to restrict write access to a set of images in write mode, to friends of one's friends using apps of a certain (set of) origins. Describing the AgentsWe want to take the intersection of a group of agents and a proof that they are using apps of a certain origin. <#AgentsWithTrustedOrigins> a owl:Class;
owl:equivalentClass [ a owl:Restriction [
owl:onProperty acl:origin;
owl:allValuesFrom </apps/SafeOrigins#>;
]] .
<#FoafWithGoodApps> a owl:Class;
owl:equivalentClass [
owl:intersectionOf ( <#AgentsWithTrustedOrigins> <#TimFoaf> );
].Of course for this to work we need to declare the Describing the ResourcesWe want to now describe a set of resources that match a certain pattern, for resources that have a pictorial representation. As mentioned in the Launcher App Proposal we need a way to find resources that match regular expressions. There we defined the <#Realm> a owl:Class;
acl:matchStarting <.>;
acl:match "**" .
<#Pics> a owl:Class;
owl:equivalentClass [ a owl:Restriction [
owl:onProperty web:mime;
owl:hasValue "image/*";
]] .
<#PicsUnderAuth> a owl:Class;
owl:equivalentClass [
owl:intersectionOf ( <#Pics> <#Realm> );
].Perhaps one should think of Putting it all together [] wac:accessToClass <#PicsUnderAuth>;
wac:agentClass <#FoafWithGoodApps>;
wac:mode wac:Write .The |
|
@bblfish it seems to me that you don't provide direct feedback on @zenomt's proposal but instead propose an alternative approach . I think it would work better to submit it in separate PR which would eliminate risk of 'hijacking' this issue and discussing all kinds of other approaches directly here. You could still later reference PR with your alternative approach in you comments on this proposal, but all the comments addressing your proposal would go in that dedicated PR.
I don't understand motivation for using those patterns, also does order in those pattern matter. Does "Read.Chat" differ from "Chat.Read" and would "Write.Chat.Read" match or not. I'd like to clarify which requirements it tries to satisfy, very likely alternative approach can clarify the same requirements while reusing already defined constructs (eg.
IMO whenever we try to put any constraints on structure of IRI we should stay extra cautious. In this case a client (RS trying to enforce ACL) makes assumption about structure of IRI on the server (RS hosting user's app authorizations). Again we should clarify which requirement it intends to satisfy. I think it relates to preventing any app to create authorization any authorization it wants for itself.
It sounds like this approach can't satisfy this success criteria from panel's README
With arbitrary tags, app can't request any specific authorizations. Related requirement also seems to appear in #31 |
Perhaps I have misunderstood @zenomt's proposal, but it seems that his main interest is to find ways to express in acls ways of limiting apps used by certain parties to a subset of resources on the server. I agree with that aim. The sketch of an ontology he proposed is an illustration on how this could be implemented. As @zenomt asked for feedback, I presented a way to do this that would fit the current deployments, and allow it to further be extended to such central use cases such as allowing friends of ones friends access to a resource. |
|
@bblfish i think you misunderstood my proposal. the principle idea is that the resource controller should not specify the origins/app-ids that the user/requestor can use, but rather each user should be able to choose what apps to use (see the "Assumptions" section at the top) including apps the controller has never heard of. the solution is an indirection/normalization step where the resource controller classifies resources, and the user can map the apps she uses onto the different classifications. this separation also allows the user to change which apps she uses and modify the privileges each app she uses has without requiring the controller to modify any ACLs. |
order matters. the patterns are arbitrary -- i gave those as examples. they're compared like with Unix/Posix shell globbing rules, so a pattern
this is to try to solve the "trusted apps" problem and the "putting origins/app-ids directly in ACLs making it hard for users to choose what apps they want to use" problem, while protecting the user's privacy around what apps she uses and what servers she accesses. edit sorry, the |
|
I really like the idea of giving control of app authorization to the user rather than the resource owner. Additionally, I like how tags essentially aren't treated as access control on the part of the resource owner. They're just ways to communicate the meaning of files so that users can apply their own access control. 2 questions:
|
agreed it's not ideal. however, in this case it's the user saying (with a claim in her webid) that this location(s) are containers and that a resource at a sub-path is permitted to make claims about authorizations she's given to an app. i couldn't think of another reasonable solution (regex? :P ) that can convey the necessary consent of the user while also preserving privacy.
the resource server is ultimately responsible for enforcing all access control (see bullet 2 in my assumptions). a resource server might not enforce or honor the user's preferences no matter what scheme is used. this proposal is for a method that can solve this problem for the user's own trusted resource server(s), and can optionally (by server configuration or ACL configuration) extend that to visitors as well.
this is an open area of research (see the second-to-last paragraph in the proposal) that i don't have a general solution for yet. perhaps this can happen via extensions to the privilege request protocol, or by messages sent to the user's inbox, or by out-of-band. i think initially it'll be your own resource server and your own tags (so you'll know them, and configure your app(s) by hand or with a permission management app), and for most cases it'll be "i care about what apps i use, but i don't care about what apps you use". |
|
Thanks @zenomt for answering my two points. I see a a requirements document as a necessity for evaluating solutions, so we should probably track that in another issue. This is more a point of criticism for this repo than it is for this specific issue; we simply cannot pick solutions without knowing exactly what they solve. Besides that, I'm not a big fan of tags as proposed here. Sentences like |
|
To @RubenVerborgh's point about a requirements document and being able to evaluate solutions, I would want to make sure that any of the suggestions promoted by this panel consider caching strategies. Because the WAC lookup algorithm is relatively expensive, computationally, it is really important that proposals lend themselves well to cache implementations: what might an in-memory cache look like? what might a distributed cache look like? |
i think tags being URIs is a good idea (which should be RECOMMENDED), but it shouldn't be required. as i mentioned earlier, the idea of tags being opaque arbitrary strings with wildcarding is borrowed from Amazon Web Services access control, and the examples i've listed above should seem comfortably reminiscent of OAuth2 scopes. certainly any default out-of-the-box tag vocabularies in a Pod/permission management system should use URIs, but there's no reason to constrain this scheme to only URIs. |
It's important to mention that with Solid, we're building systems with a desired level of interoperability beyond what has ever been created before. So the existence of a certain technique is by itself not necessarily a good indicator for fitness for Solid. For instance, Amazon Web Services also use usernames (or e-mail addresses), but we're not arguing that WebIDs could be usernames instead of URLs. |
If the aim of the proposal is to limit which apps should be used for which types of resources, and that this should be specified by the client -- as indeed the trusted apps section of the WAC spec indicates -- then this could perhaps best be done by the Launcher App. The Launcher App could write down for each App a set of constraints on where the App can authenticate to edit data using something similar to the ontology I described above, and then only give tokens to apps for resources that fit that restriction. It seems to me like the Launcher App would be better able to enforce such restrictions than the resource server, thereby leaving the resource server the job of more coarse grained restrictions. (Even though as I showed the resource server could follow some such rules too). It may be that for some use cases it would be helpful for resources to publish metadata about the type of data they contain that goes beyond mime types, so that the Launcher App could use is rules that limit an App to writing files with certain kind of data. Eg: the calendar App could be restricted to only calendar type data, and enforce that by looking at the metadata of the resources. |
|
followups from today's panel meeting: @jaxoncreed mentioned (as i understood him) a treatment of users and apps in a similar manner, which sounded to me a lot like Attribute Based Access Control (ABAC). i believe ABAC would be a substantial change to the semantics of today's WAC, and deserves its own issue and research independent of this proposal. i think related to this was the idea of having a permission/mode mask in the while considering the above, though, i thought it might be desirable to have a "default" AppAuthorization for an app (which could be created on initial app permission setup or something) that could have an speaking of universal-ish tag vocabularies and the user's cognitive load (@dmitrizagidulin), i had envisioned that a practical Pod for ordinary users would come pre-configured with containers for common stuff (like Photos, Chats, Documents, Whatevers), with reasonable default ACLs (that could include reasonable classifications via reasonable tag vocabularies), and come with a reasonable default permission control app that could come pre-configured with a curated set of useful tags to easily apply to new resources/collections as well as to new apps. |
|
@jaxoncreed for permission masks: what if the user's application tags were only for specific access modes, so you could say "this app has and of course an also, i implemented support for a default note that the owner/controller is free to assign different tags for different access modes too, giving lots of flexibility. edit: i implemented |
|
@zenomt If I understand this correctly I think this could work. To confirm, the resource owner would be able to use |
|
@jaxoncreed the resource owner would just use edit: in other words, |
|
since opening PR #62, i propose closing this issue as redundant and outdated. |
|
Sounds good |
This proposal is to replace the "trusted apps" mechanism, and to augment the
acl:originmechanism in WAC, to allow resource owners to control the access different of their apps have to their different resources, by introducing the notions ofThe proposal allows each user to have independent mappings of apps to tag patterns, provided the resource server is configured to enforce the visiting users' app access preferences.
If this proposal resonates with folks, I'll prepare a more formal specification as a PR.
Assumptions
Proposal
Note:
acl:appis similar toacl:origin, only allowing finer-grained app identification (for example, with an OAuth2redirect_uri), and allowing matching by prefix instead of exact match (so thatacl:app "https://app.example/oauth/"matches an app-id ofhttps://app.example/oauth/code). Other new terms inacl:used here are assumed for now to be obvious from context.The resource owner/controller can specify one or more tag patterns in an
acl:Authorizationinstead of anacl:originoracl:app. Tag patterns can include wildcards (*and?characters) and use traditional shell globbing rules to match. Example ACL:If any of the tag patterns that the user has assigned to the app that she's using matches any of the tag patterns in the
acl:Authorization, then it's as if there was anacl:appmatch. Note that there is no global vocabulary of tags/scopes; tags are arbitrary, and what tags to assign to authorizations is entirely at the discretion of a resource owner. Tags SHOULD have the same meaning at least across resources in the same origin and realm.The user associates tag patterns for the combination of an app, resource server origin, and security realm (the name of the protection space; that is, the
realmauthentication parameter of theWWW-AuthenticateHTTP response header) in an App Authorization document. Tag patterns here can also include wildcards (*and?) and use the same globbing as tags in ACLs. Here is an example App Authorization document assigning tag patternsBooks.ReadandChat.*to apphttps://app.example/oauth/codewhen accessing serverhttps://mike.example's realm/auth/:The URI for the App Authorization document MUST be in (at a sub-path of) an
acl:appAuthorizationsin the user's profile (otherwise the resource server MUST ignore it):This container/directory SHOULD be configured to allow read of App Authorization documents by anyone and any origin; however, to protect the user's privacy (specifically, what apps the user uses and what resource servers the user accesses with those apps) including from other apps the user uses, listing the container's contents should be restricted to only the user, and then to only the user's trusted authorization management app.
The method by which an app discovers its App Authorization URIs is to be determined. I envision that each app will have an App Authorizations index file, generated and maintained by the user's trusted authorization management app, stored in a non-listable container, with a URI derived from the app's identifier, and readable only by the user and only when using that app, mapping between App Authorization URIs and resource servers, for example:
The non-listable container for App Authorization index files SHOULD return identical HTTP
403responses both for accesses to non-existent index files and for accesses to existing index files which are not for the user∙app requesting it, so that an adversary (other user or other app) can't probe for index files to discover what apps the user might use.The method by which the tag vocabulary being used by a server is communicated to the user or to the user's trusted authorization management app is to be determined. I envision that a method could integrate with the HTTP Privilege Request Protocol.
To associate tags with a
Beareraccess token, the app sets theapp_authorizationskey in the proof-token/POPToken to be the URI of the App Authorization appropriate for this server∙realm. The server verifies the App Authorization URI as being in one of the user'sacl:appAuthorizationscontainers, and (re)loads/revalidates this document at least as often as the user's profile document. The server applies any tag patterns in this document that are for this server∙realm and the app being used, to match against tags inacl:Authorizationsfor which the user would otherwise be permitted.The text was updated successfully, but these errors were encountered: