Feature #2328
Updated by Tim Pierce almost 10 years ago
The proposed permissions model for Keep is as follows: A Keep locator string may end with a _permission hint_ in the form "+Asignature@timestamp". If a Keep server is configured to enforce permissions (via the --enforce-permissions flag), then GET requests for blocks must supply a block locator with a valid permission hint. If --enforce-permissions=false, then the server will accept both signed and unsigned locators, and will not attempt to verify signatures. The _signature_ string here is a cryptographic hash consisting of alphanumeric characters, and _timestamp_ is a 32-bit Unix timestamp expressed as an 8-digit hexadecimal number. a 32-bit integer. A valid permission hint grants the user the ability to GET that GET, PUT or DELETE an object in Keep. Keep; permission is all-or-nothing. The permission hint may be generated either by Keep (after the user writes a block) or by the API server (if the user has @can_read@ permission on the specified object). The hint Keep and API server share a secret that is a SHA-1 hash generated used to generate signatures. Permission hints do not incorporate secrets from the user; if another user acquires a combination of locator that includes a server key (shared by Keep and the API server), the user's API token, and an expiration timestamp. valid permission hint, they have permission to GET, PUT or DELETE that object. To verify a permission hint, Keep generates a new hint for the requested object (using the locator string, the timestamp, the permission secret and the user's API token, which must appear in the request headers) and compares it against the hint included in the request. If the permissions do not match, or if the API token is not present, Keep returns a 401 error. GET and HEAD: * Keep server expects each read request to come with an API token (in HTTP headers) and a string +Asignature@timestamp (appended to the block hash) * if the timestamp is in the past, 403. * if the signature is invalid, 401. PUT: * Keep server expects each write request to come with an API token (in HTTP headers) * Keep server generates a +Asignature@timestamp string and appends it to the hash in the response after a successful PUT Reference: * "Ruby code for generating and verifying signatures":https://arvados.org/projects/arvados/repository/revisions/master/entry/services/api/app/models/blob.rb The following Desired command line arguments are used to configure permission generation and enforcement: control permissions: * @--permission-key=key@ sets the server's secret key to @key@. If this argument is supplied, PUT requests will be required to include an OAuth token, and Keep will respond to PUT requests with a signed locator string. * @--data-manager-token=tok@ identifies an OAuth token that will be used by the Data Manager. Requests that include an OAuth token of _tok_ will be allowed to perform privileged operations (@GET /index@ and @DELETE@). * @--enforce-permissions=@ @--enable-permissions=@ _true/false_ to enable or disable permission enforcement. enforcement ** If @--enforce-permissions=true@, the server will reject any GET requests for blocks that lack For transition, maybe support a valid signature, @--generate-permissions@ flag and will permit @GET /index@ and @DELETE@ requests from a @--enforce-permissions@ flag. ** Alternatively, make Keep always generate permission tokens, but only enforce them when the data manager. perms flag is turned on. ** Permissions are always required for DELETE * @--privileged-ip@ specifies IP addresses to be considered superuser. ** If @--enforce-permissions=false@, the server will fulfill GET requests without regard to permission signatures. It will also prohibit @GET /index@ permissions are disabled, index (@GET /index.txt@) and @DELETE@ requests entirely. do not work unless remote address matches @--privileged-ip@ command line argument * @--signature-ttl=num_seconds@ to control expiry time of signatures * @--signature-key-fd=fdnum@ to read signing key from given file descriptor