-
Alice uses an UMA-protected cloud file system API (RS), with files and
folders as protectable resources.
-
Folders have scopes read, write, and search.
-
Files have scopes read, write, and execute.
-
Folders can contain files and other folders, and any one file can more than one "folder parent". However, this is known only to the RS, not to the AS.
-
The RS is able to tell a distinct RO and AS for every location URI for a file or folder by means of an internal mapping process.
-
Alice has resources with names as follows (let's use the name as the ID, for clarity of discussion):
-
folder "deciduous-trees'
-
folder "evergreen-trees"
-
file "birch" in folder "deciduous-trees'
-
file "larch" in folder "deciduous-trees'
-
file "fir" in folder "evergreen-trees'
-
file "yew" in folder "deciduous-trees' and folder "evergreen-trees"
We need to answer the following questions (and which others?):
-
The client attempts to read file "birch".
-
Presumably the RS can request permission birch:read from the AS on the client's behalf. Can it request:
-
birch:read+write and also larch:read+write?
-
Only deciduous-trees:read without birch:read if its access control semantics (something like "folders contain/cover files") means that access to a folder confers access to contained files?
-
Only birch:write? Our current UMA1-based wording says no since this wouldn't be sufficient for what the client attempted.
-
What other permutations?
Cigdem: Can another permutation be?
RS registers only permission birch: read. In authorization assessment stage, AS checks permissions for birch for the specific client, given by RO. If they include write or execute, then may the AS return a token with birch:read, birch:write, birch:execute?
This may be useful if the client is expected to attempt a write after a read. Here, AS expands the token based on the RO permissions (assuming client can handle these scopes, registered for them etc., which is another parallel discussion).
To me, the answers to these questions will depend on how the resources were registered for protection in the first place, and what granularity the resource owner grants permissions.
AS will not know the file/folder structure and will operate on which resources were registered. So, does the resource server register a file and, separately its encompassing folder? Does RO create policies separately at both file and folder level? i.e., does
RO allow some clients access to specific files within folders, and some others to an entire folder and everything underneath it?
In the first suggestion, if RS asks for birch:read+write and larch:read+write, and these resources are registered at AS and scopes are valid, AS will return a permission ticket. When the client presents the permission ticket, if the client is only permissioned
to read birch then, I expect, AS will scope down the request (but client did not ask for that action in the first place). Per UMA text, alternatively, the AS may interact with the RO to authorize access attempt in near-real time to get permission for larch:read+write
. But, the client has not attempted access to larch and did not even want a write.
Finally, let’s assume RS registered a permission for deciduous-trees:read. If the RO did not give permissions at the folder level to this client, should the AS reject or try to return a minimum token for the folders in that folder? But then AS does not know
the folder structure. If birch was registered separately, then it may be that RO gave permission only to birch:read. If the request is rejected, this is confusing, because the client asked only for birch:read and its request is denied because the RS registered
an elevated permission. In this case, the policy at the AS does not need fixing, neither the AS behavior. But RS should not have elevated the permission request. Can RS reliably make decisions on which requests to elevate without knowing RO policies (which
only AS knows)?
Thanks,
--Cigdem