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]

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.