Hi, I do really like Kirilo's ideas, I do think that there should be a way to limit API keys to an IP address/prefix. My main concern is that I would like it to remain separate from the LIR portal, if there is a way to do this without relying on the LIR portal, I am all for it :) I don't want too many features in the RIPE DB to rely upon the user being an LIR. - Cynthia On Mon, Mar 16, 2020 at 11:52 AM Kirilo Vasiļiskovs via db-wg <db-wg@ripe.net> wrote:
Hello,
I also vote for a proper way of doing things. Normally APIs have their own ways of access management. Some of API key features are essential for access control: - API keys can be easily regenerated without changing normal account access (ok, this one is arguable benefit as we can just change the MD5 password if needed) - API keys and APIs have some mechanism to restrict access to just certain IPs (I don't remember this feature for MD5 passwords at all) - NOC people that have access to mntner objects and software developers are often different people, and so their access should be specifically limited to their job (e.g. giving API keys to the developers instead of the full access to mntner object).
That's just a few advantages from the surface of my mind. I guess other people can add more.
Respectfully / Ar cieņu, Kirilo Vasiļiskovs.
ср, 11 мар. 2020 г. в 13:22, Sebastian Wiesinger via db-wg <db-wg@ripe.net>:
* Tore Anderson via db-wg <db-wg@ripe.net> [2020-02-21 11:54]:
Hi WG.
In the LIR Portal, at https://lirportal.ripe.net/api/, it is possible to issue API keys for use with several different RIPE NCC services.
However, it is unfortunately not possible to issue API keys for the two APIs that are used for database maintenance; Syncupdates and the RESTful API. The documentation implies that the only authorisation [sic] method for those APIs is MD5-PW.
Hello,
I would support a modern approach to authorisation with the WEB API. I don't think it should be bound the LIR portal (as there might be users who are not an LIR). But some sort of API-friendly authentication for maintainers would be appreciated, maybe coupled to SSO user accounts. Just sending the password as an URL parameter is not really a modern approach, also you would need to change the maintainer password every time someone leaves the company.
Best Regards
Sebastian
-- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant