Hi Daniel, Thanks for your feedback,
On 19 Sep 2024, at 13:00, Daniel Suchy via db-wg <db-wg@ripe.net> wrote:
Hello,
On 9/19/24 12:33 PM, Edward Shryane wrote:
This in turn makes the API keys unsuitable for use by automated systems (e.g., integration with an IPAM system), as one certainly do not want those to stop working simply because the person who created the API key in the first place quit the company and had their user account deleted. If IPAM integration stop working, it must be straightforward to identify the cause and solution (i.e. that API key no longer works, generate a new one).
That's typical "developer's" reaction... make it someone else's problem.
If the IPAM system stops working, it must be clear what caused it, so it can be fixed, regardless of the reason.
But there's another reason why it's better to have the API keys associated with the organization and not with individual accounts.
In case of key compromise, it needs to be invalidated as quickly as possible. Anyone from the organization must be able to do this. From the point of view of the organization, it is very important to see ALL active keys. And not to think about whether a specific user generated an API key or not. NIS2 makes this even more critical for many organizations.
Any administrator can already remove an SSO user from their maintainer if they are suspected to be compromised. Per-organisation keys are harder to control as more than one person can know what they are. It is more difficult to identify who made changes if you have a shared key. Also, if someone leaves the organisation you should invalidate *all* keys that they had knowledge of, rather than the per-user model where you can just remove the user. How do you share per-organisation keys securely? If we display a list of all active keys, then we must keep the plaintext keys on the server-side, which increases the risk of exposure for the RIPE NCC and the organisation. It's good practice when generating a key for a user to only display it once, and then store only the hashed version on the server side. It's the users responsibility to keep it secret. It is possible with the per-user API key model to display a summary of API keys for all users and when they were last used. You can manage users instead of knowing about individual keys.
Yes, this can be somewhat circumvented by organization shared account. But that's not the best solution from a security point of view. But this still won't solve the problem that other user will generate a key for himself as well.
Shared credentials are a security risk, as you don't know who made changes, it is harder to know when they have been compromised. The API key should be known only to the SSO user, that is how they authenticate themselves (the same as their password and 2FA is known only to them), and kept separate from their role (their authorisation to act on behalf of the organisation).
Sure, we try to graft new things onto the really old database. But the maintainer object should be a I think associated with the organization, company. Not with a person. It's not that easy with SSO authorization (like webupdates), but that's easy with API keys. This just wants to change perspective and not try to tie everything to a person.
The authentication part (i.e. the user identifies themselves via an SSO session or API key) should be kept separate from the authorisation part (i.e. this user is allowed to make changes on behalf of our organisation). These two concepts are conflated in the RIPE database model but should be separate (and can be, with SSO accounts and API keys to identify the user).
Security cannot really be solved by saying "and that's your problem".
So I support idea of having API keys linked with organisation. From a security point of view, it will be more transparent.
- Daniel
Thanks again for your feedback. I will discuss your proposal internally to see if we can improve the design (the features of API keys have not been finalised yet). Regards Ed Shryane RIPE NCC