Add security to redirectToOrigin API

[joereuss12]

Pelican Service:

• Client
• Plugin
• Registry
• Director
• Origin
• Cache
• Other (please give the detail)

When working through the redirectToOrigin API looking into direct reads, @jhiemstrawisc and I discovered a potential vulnerability within the redirectToOrigin. A user can bypass the directread check and talk directly to an origin using another client by simply utilizing the api call /api/v1.0/director/origin. This would allow users to not set directreads but talk directly to an origin anyway and could lead to exploitation of the origin.

[bbockelm]

Isn't this a "works as designed"?

Unless you use the connection broker, the origin is on the public internet and will service any request. You can also get this information from the web interface.

In the future, we could consider requiring a second authorization to ensure the client is from the federation -- but for now, a public origin is open to the internet.

[jhiemstrawisc]

I think this does warrant some additional discussion -- if an origin indicates it doesn't want non-cache clients reading directly from it, how should we handle that? We could make that a decision in the director by refusing a redirect, or the origin itself could refuse non-cache clients. If we have a toggle for DirectReads in the origin and the namespace export, shouldn't we find a good way to enforce that?

[bbockelm]

One potential approach would be to have the caches request a token from the director (this request can be authorized by a token generated by the cache) indicating that it is a valid cache in the federation.

Then, the cache would present the token as a separate header in the HTTP request to the origin; the origin would require any request present a cache token in addition to the client's token.

To do this, we'd need:

1. Changes in the cache and director to provide the cache with a token. The pelican process for the cache would keep a token on-disk up-to-date.
2. Changes in xrdcl-pelican to pick up the token from the disk and add it as an extra header in its HTTP request to the origin.
3. A new plugin for xrootd to verify the cache token (or a change to the existing SciTokens plugin so it can be loaded twice and look at a separate header).

Further, before enabling, we'd need all caches to be at the minimum version that sets the token in the headers -- meaning this is probably a 3-6 month transition period if we took this direction.

[bbockelm]

Ultimately, this boils down to "what is a cache client?". Since we use bearer tokens, there's currently no way to distinguish Pelican end-user clients versus caches.

I think this is more of a discussion/design topic, not an issue. Going to convert it over to the discussion page.