* Edward Shryane
Introducing API Keys --------------------
In addition to the existing alternatives, we also propose to introduce API keys linked to an SSO account to replace passwords, that is convenient and secure.
An API key is an auto-generated string associated with a user account that can be used to authenticate updates on behalf of that user. They are already widely used across the Internet, although by different names (e.g. GitHub Tokens, Google Application Passwords, AWS does use API keys, etc.). Other RIPE NCC services already make use of API keys, for example the LIR Portal and RIPE Atlas.
We are investigating how to create a new service to allow RIPE NCC Access accounts to generate API keys that can be used to authenticate updates to the RIPE Database.
The advantages include: * RIPE NCC Access accounts are associated with a maintainer in the RIPE database and not any API keys, so there are no credentials that can be leaked. * API keys can be associated with a SSO account, so there is accountability to identify who authenticated an update. * We can automatically expire API keys after a certain time limit for increased security, in case they are leaked. * Users can more easily migrate away from passwords as API keys can be used in the same way.
Hi Ed, I'm very supportive of the idea of being able to use API keys to maintain the RIPE database content. However, I'd like to point out a fundamental difference between MD5 passwords and the API key implementation you outline, namely that the MD5 passwords are per maintainer while the API keys are per user account. This means that they cannot actually be used in the same way, because a maintainer password will keep working even as LIR staff rotate, but a user's API key will not. 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. To remedy this I suggest that you make it possible to create API keys on the LIR account level as well, i.e., independent of individual user accounts. Tore