-
Notifications
You must be signed in to change notification settings - Fork 11
Description
In Pelican, we heavily use the XrdSciTokens plugin (in src/XrdSciTokens directory of github.com/xrootd/xrootd) to decode authorization tokens and apply authorization policy.
There's a desire to enable the use of pure capabilities and to experiment with more drastic changes to the authorization model. I would prefer if we implement the experiments once, in Go, rather than doing the round trip through XRootD.
So, let's implement an XrdAcc plugin that uses the XrdCl client code (with the HTTP backend; look at https://github.com/PelicanPlatform/xrdcl-pelican/blob/main/src/XrdClS3/XrdClS3File.cc to see examples of doing this) to make a HTTP request to a configured endpoint to determine what to do with a given token.
The HTTP GET request to the endpoint should include in its query arguments the (URL-encoded) path that is being requested and the corresponding HTTP or WebDAV verb. The token provided should be passed through as a bearer token in the Authorization header. The response's status code should indicate what to do with the token (200 -> authorize; 401/403 -> deny; 5xx -> error executing the plugin). Like XrdSciTokens, it should be configurable whether to pass through to the next configured plugin on failure or fail completely.
The response should be cached for a configurable amount of time (up to a minute). There should be a separate lifetimes (all configurable) for positive and negative responses.
The body of the response may contain additional data in JSON format. These can include:
- Authorizations to cache: if the token permits not only the given object but specific prefixes (which may allow the lookup to be skipped for other requests), these can be given in the body. These should have the form of HTTP verb and path prefix.
- User and group data to add to the security context as additional info. This information may be used by the backend storage providers for security information lookup.