numbered work item suggestion: support PGP authentication with whois-api
Hello WG, I'd like to propose an enhancement of the whois REST api to support PGP authenticated POST requests for create,update,delete methods. Currently the API doesn't support this, so you have to use the REST interface to download objects and the MAIL interface to modify them if you don't want to use password authentication. A consistent user interface however, would be more reliable, easier to understand and maintain. Thanks in advance, Thomas von Dein -- Thomas von Dein <admins@f-i-ts.net> Finanz Informatik Technologie Service GmbH & Co. KG, OE 76052 Tel:089/94511-8833, Fax:089/94511-8941, http://www.f-i-ts.net
Thomas, I do agree that the currently used method for authentication is dated and could be modernized. From your perspective, why is PGP support preferred over a more modern API approach like Oauth2? While I am not against the use of PGP authentication, I do feel that a better approach would be through using technologies that are typical for this kind of application (like Oauth2). Thanks, William Sylvester
On Nov 1, 2016, at 7:06 AM, Thomas von Dein <tom@f-i-ts.net> wrote:
Hello WG,
I'd like to propose an enhancement of the whois REST api to support PGP authenticated POST requests for create,update,delete methods.
Currently the API doesn't support this, so you have to use the REST interface to download objects and the MAIL interface to modify them if you don't want to use password authentication.
A consistent user interface however, would be more reliable, easier to understand and maintain.
Thanks in advance, Thomas von Dein
-- Thomas von Dein <admins@f-i-ts.net> Finanz Informatik Technologie Service GmbH & Co. KG, OE 76052 Tel:089/94511-8833, Fax:089/94511-8941, http://www.f-i-ts.net
Hi William, On Tue, Nov 01, 2016 at 02:32:38PM +0000, William Sylvester wrote:
why is PGP support preferred
I do not prefer, it's just what I currently use and what looks most secure.
over a more modern API approach like Oauth2?
Well, "modern" is tomorrow's crab. So, be it Oauth2 or something else as long as it's secure, understandable, reliable and consistent. best, Tom
On Wed, Nov 02, 2016 at 01:20:05PM +0100, Thomas von Dein wrote:
over a more modern API approach like Oauth2?
Well, "modern" is tomorrow's crab. So, be it Oauth2 or something else as long as it's secure, understandable, reliable and consistent.
Ok, since there are no responses, let me explain the comment more detailed. As far as I know, RIPE doesn't provide Oauth based login for API access yet, only password based authentication. We cannot use this, since we don't have a password set on our maintainer object and we don't intend to change this. PGP based authentication on the other hand is already implemented elsewhere with RIPE (autodbm), hence the suggestion to use it in the REST API as well. One more thing about Oauth: you'd need an external provider for authentication forwarding. Which? And why shall I introduce another entity into the process? Also, building our own provider just for updating objects doesn't make any sense. Also, it's insecure [1], at least as it's implemented currently on most sites. So, the easiest way to implement this would be (for example) to introduce a query parameter 'signature' which contains a base64-encoded PGP signature of the current POST-data, which could be verified by the backend. Or something like this. best regards, Tom 1) http://insanecoding.blogspot.de/2016/04/oauth-why-it-doesnt-work-and-how-to-... -- Thomas von Dein <admins@f-i-ts.net> Finanz Informatik Technologie Service GmbH & Co. KG, OE 76052 Tel:089/94511-8833, Fax:089/94511-8941, http://www.f-i-ts.net
Currently the API doesn't support this, so you have to use the REST interface to download objects and the MAIL interface to modify them if you don't want to use password authentication.
You can use PGP authentication via the syncupdate interface (via HTTPS) rather than having to revert to MAIL. I do support the concept of improved authentication of some flavour for REST though. Ian Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
participants (4)
-
Dickinson, Ian -
Thomas von Dein -
Thomas von Dein -
William Sylvester