My main issue with API Keys is them being attached to SSO accounts. What about when the employee leaves the company?

He gets removed from auth on the mntner, all the apps he set-up break? Making admins hesitant about removing user access.

API access needs to be bound to the mntner in some form imho.

Additionally, would api keys allow querying the API and getting unfiltered data? Or would it just be for `post`ing updates to objects?

I suspect the signed updates have little usage for two major reasons:

Figuring out if the update succeeded requires receiving and parsing emails
Figuring out if the object is up to date on the ripe database is practically impossible* due to filtering (auth: SSO# Filtered)

Sending requests with x509 client cert auth means you know who is sending the request and you have no need to filter data (like the auth sso entries) out for objects the mntner has permissions for, making idempotent api clients so much easier to make.

The logic i might want to implement, in pseudocode:

while true

mntners = database(mntners)

foreach mntners as mntner

objects = rest api request for all objects with mnt-by = mntner

foreach objects as object

if object not in database

notify admin .... or delete it

continue

if object == database(object)

rest api request to update object with data from database

p.s. sorry about my earlier, mangled email, my email client seems to have gone a bit nuts...

* okay not "impossible" but really annoying, you'd have to store the last updated timestamp from ripe, for all objects, and if it changes in the ripe db, then we'd have to post the object to see if it changes?

From: Edward Shryane
Sent: Wednesday, March 18, 2020 15:29
To: Gunnar Guðvarðarson
Cc: Tore Anderson; db-wg@ripe.net
Subject: Re: [db-wg] API keys for database maintenance

Hi Gunnar,

We're indeed also working on Client Certificate authentication (we have tested it, and now it's pending a security review).

However, to make use of this, a user must:

- Generate an X.509 certificate
- Extract the certificate as text and create a key-cert object from it
- Associate the key-cert with a maintainer in an auth: attribute
- Configure the Whois client to send the client certificate when connecting to the REST API (or Syncupdates).

This is not trivial to do, and we can see that although signed updates are supported in Whois, it has low usage.

It is still worthwhile to support this, as the credential (secret) is only stored locally on the client.

Hopefully API keys will be more "user friendly" and can be used in preference to MD5 hashed passwords.

Regards
Ed Shryane
RIPE NCC

> On 18 Mar 2020, at 09:45, Gunnar Gušvaršarson <gunnar.gudvardarson@advania.is> wrote:
>
> Hey,I think that if we get x509 client certificate authentication for the API working, it might even be easier.
> All the UI to add certs and auth them on mntners is already there, the web services just need endpoints that request and use client provided certs.
> https://github.com/RIPE-NCC/whois/issues/534