From msdemlei at ari.uni-heidelberg.de Thu Nov 21 09:45:52 2024 From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner) Date: Thu, 21 Nov 2024 09:45:52 +0100 Subject: [Ops] VO-wide API keys Message-ID: <20241121084552.6istuaql2fzfwzcz@victor> Dear Ops, dear GWS, At the recent Interop, IPAC announced they would soon have to introduce per-user API keys; these are not really for (strong) authentication, but mainly to be able to throttle overly eager users and to be able to advise them on good manners via e-mail if necessary. Now, it would be bad UX if users and clients had to manage a bunch of API keys (and methods for how to present them) for the various major VO services in case more operators went that way. So, *if* we have to have them, let's make it such that they are VO-wide from the start. A single key-generating service (or at worst very few of them) should hand them out, and hopefully all API-key-using services would accept them. The way I think this could work is that the key store generates a uuid and then signs it; it gets associated with an e-mail address, but that address is only retained (with the UUID) at the key store. With ed25519 signatures, the resulting API key would still be compact enough, I suppose, probably just one text line in base64. The key store then publishes the public key of the signing key used, so if I want to check an API key I just check for a valid signature with that key and be done with it. If I really want to uncover an identity, I'd extract the UUID and ask the key store, which admittedly *might* incur a minor amount of extra admin work there, but really, I'd be surprised if these kinds of requests came in more often than once per week or so. If we found we needed it, we could even have revocation lists (signed with that same key), but frankly I think we can think about that when that turns out to be a use case (which I don't expect). Perhaps some sort of built-in expiry could be that we rotate the signing key every two years or so. Data centres could then easily validate signatures for the past six years or choose to just go two years back by choosing with private keys they use for signature checking (but I'm not wild about expiring keys, very frankly: crypto is hard enough without timebombs). Note that this is not strong authn, mainly because clients would likely be handing out the API keys to anyone on request, and then anyone operating such a service could collect API keys. We *could* make it so the service has to prove something to the client before the client hands out the API key to mitigate the problem of API key stealing, but frankly, I'm sure that's overengineering for the sort of thing we want to do here (control users overstressing our services without evil intent; perhaps control access to persistent TAP uploads). If you want an API key, go to the key store, and the benefits of having someone else's API key look very minor (well: if we did persistent uploads by API key, you could read other persons' tables. Hm). If some system like this already exists in the wider Web, even better (I have to admit I have largely given up following all the adventurous schemes for Web Authn and its environs). Then let's just adopt that. But if not, I think this would be a nice, quick, and simple way to have a halfway privacy-respecting solution for the overeager user problem. I'd be in on writing a short Note hashing out the details. Thanks, Markus From msdemlei at ari.uni-heidelberg.de Thu Nov 21 09:45:52 2024 From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner) Date: Thu, 21 Nov 2024 09:45:52 +0100 Subject: [Ops] VO-wide API keys Message-ID: <20241121084552.6istuaql2fzfwzcz@victor> Dear Ops, dear GWS, At the recent Interop, IPAC announced they would soon have to introduce per-user API keys; these are not really for (strong) authentication, but mainly to be able to throttle overly eager users and to be able to advise them on good manners via e-mail if necessary. Now, it would be bad UX if users and clients had to manage a bunch of API keys (and methods for how to present them) for the various major VO services in case more operators went that way. So, *if* we have to have them, let's make it such that they are VO-wide from the start. A single key-generating service (or at worst very few of them) should hand them out, and hopefully all API-key-using services would accept them. The way I think this could work is that the key store generates a uuid and then signs it; it gets associated with an e-mail address, but that address is only retained (with the UUID) at the key store. With ed25519 signatures, the resulting API key would still be compact enough, I suppose, probably just one text line in base64. The key store then publishes the public key of the signing key used, so if I want to check an API key I just check for a valid signature with that key and be done with it. If I really want to uncover an identity, I'd extract the UUID and ask the key store, which admittedly *might* incur a minor amount of extra admin work there, but really, I'd be surprised if these kinds of requests came in more often than once per week or so. If we found we needed it, we could even have revocation lists (signed with that same key), but frankly I think we can think about that when that turns out to be a use case (which I don't expect). Perhaps some sort of built-in expiry could be that we rotate the signing key every two years or so. Data centres could then easily validate signatures for the past six years or choose to just go two years back by choosing with private keys they use for signature checking (but I'm not wild about expiring keys, very frankly: crypto is hard enough without timebombs). Note that this is not strong authn, mainly because clients would likely be handing out the API keys to anyone on request, and then anyone operating such a service could collect API keys. We *could* make it so the service has to prove something to the client before the client hands out the API key to mitigate the problem of API key stealing, but frankly, I'm sure that's overengineering for the sort of thing we want to do here (control users overstressing our services without evil intent; perhaps control access to persistent TAP uploads). If you want an API key, go to the key store, and the benefits of having someone else's API key look very minor (well: if we did persistent uploads by API key, you could read other persons' tables. Hm). If some system like this already exists in the wider Web, even better (I have to admit I have largely given up following all the adventurous schemes for Web Authn and its environs). Then let's just adopt that. But if not, I think this would be a nice, quick, and simple way to have a halfway privacy-respecting solution for the overeager user problem. I'd be in on writing a short Note hashing out the details. Thanks, Markus