[Ops] VO-wide API keys

[Markus Demleitner]

Dear Rick,

On Thu, Nov 21, 2024 at 12:44:08PM -0800, Rick Ebert via ops wrote:
>     The services only need proof that the client _has a valid service
> key_
>      the key should probably NOT be sent to the services ...
>      as it is likely these api keys will be ... "long-lived" ...

+1 to long-lived.  If people need to renew them more often than, say,
every six months, it'll be a chore (on the other hand, of course,
they'll have forgotten about how to do it after six months... hm).

On not sending API keys to the service... well, that increases
complexity by a large margin (you probably need challenge/response
then). Also: how would this be different from full Authn?

Me, I'd say there are two fairly different use cases:

(a) block rude users/perhaps be able to contact them

(b) control access to proprietary resources

While for (b), I have some sympathy to the notion that we want to
protect the credentials from stealing, I don't see that as a major
problem for (a); anyone can obtain API keys anyone, and cloaking as
someone else probably won't buy you much in our setting.  Basically,
you could DoS another person until they get a new API key.  Yawn.

So, my vote would be for not linking API keys to the more general
problem of federated Authn and look for the absolute minimum that can
possibly work.

> I further second the "adopt an existing deployed mechanism" criteria.

Sure, that would be nice.  The only place I am using something like
this is for the ADS API; for them, the key just rides in an
Authorization: bearer: HTTP header, and I suspect the the string you
get has no internal structure (at least it doesn't seem to be
base64-encoded).  Is anyone aware of systems closer to the digital
signature thing that I'd like[1] to have?

          -- Markus



[1] No, not "like".  Make that: "That I'd least dislike if we have to
annoy our users with API key management in the first place."