Hey, 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) continue rest api request to update object with data from database sleep for a while -- 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; [email protected] 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 > <[email protected]> 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
