Actors: cloud-subscriber, unidentified-user, cloud-provider
Goals: A cloud-subscriber makes access to objects stored in a cloud-provider selectively available to other cloud-subscribers and unidentified-users.
Assumptions: The cloud-provider provides an Access Control List (ACL) for each data object and for each data object container. An ACL contains a set of ACL entries, each of which lists a set of permitted access modes (e.g., read, write, delete, append, truncate, traverse) and the identities of a set of cloud-subscribers to which the modes apply. The unidentified-user is a pseudo-cloud-subscriber for which access rights are specified. The ACL for a new object-or-container is initialized with a default value that a cloud-subscriber can set. A cloud-subscriber has administrative access to the ACLs of a set of data objects.
Success Scenario (change-ACL, IaaS, PaaS): A cloud-subscriber who owns objects sends a request to a cloud-provider to change the ACL for one or more of those objects. The request specifies the object identifier for each object's access modes that should be affected. The change may be the addition or deletion or edit of an existing ACL entry. After the request has been processed, object access requests from the specified cloud-subscribers and unidentified-users will be checked in accordance with the new ACL by the cloud-provider.
Failure Conditions: (1) a cloud-subscriber or unidentified-user attempts to modify the ACL (in order to give others access to an object) although the cloud-subscriber or unidentified-user does not active permission to do so.
Failure Handling: For (1), the data object's owner with the correct permissions will need to make the ACL modification request to the cloud-provider.
Requirements File: NA
Credit: ACLs have been included in many systems and specifications, including POSIX.1e.