RIPE Database Release 1.72 - including SSO Integration
Dear colleagues, We are pleased to announce RIPE Database release 1.72. For more information about the features, changes and how this release might affect your operations, please see these release notes: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.72 A major feature introduced in this release is the integration of RIPE Database services with RIPE NCC Access. This gives maintainers the option to use their RIPE NCC Access account for authorising updates to the RIPE Database. The first applications that utilise this feature are Webupdates and Syncupdates from a web form. Linking a RIPE NCC Access account to an organisation is a requirement for certifying PI address space. No change has been made to existing authorisation options. This release also fixes a number of issues, so please read the release notes. By fixing certain issues with the JSON output from the REST API, the structure of that output has changed slightly. This should not affect any users as it was broken in the first place. To ensure this is the case, please test your implementation in the Release Candidate environment. More information about the Release Candidate environment is described in this document: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-enviro... We look forward to hearing any questions or comments you might have. Regards, Denis Walker Business Analyst RIPE NCC Database Team
Dear Colleagues The RIPE Database release 1.72 has now been fully deployed to production. We would like to point out that, with this release, Webupdates and Syncupdates can only be accessed with HTTPS and not with HTTP. This is to conform to the requirements of using RIPE ACCESS now as an authentication method for updating the RIPE Database. Any update using HTTP will be automatically redirected to HTTPS. Regards Denis Walker Business Analyst RIPE NCC Database Team -------- Original Message -------- Subject: RIPE Database Release 1.72 - including SSO Integration Date: Thu, 06 Mar 2014 17:15:16 +0100 From: Denis Walker <denis@ripe.net> Organization: RIPE NCC To: Database WG <db-wg@ripe.net>, NCC Services WG <ncc-services-wg@ripe.net> Dear colleagues, We are pleased to announce RIPE Database release 1.72. For more information about the features, changes and how this release might affect your operations, please see these release notes: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.72 A major feature introduced in this release is the integration of RIPE Database services with RIPE NCC Access. This gives maintainers the option to use their RIPE NCC Access account for authorising updates to the RIPE Database. The first applications that utilise this feature are Webupdates and Syncupdates from a web form. Linking a RIPE NCC Access account to an organisation is a requirement for certifying PI address space. No change has been made to existing authorisation options. This release also fixes a number of issues, so please read the release notes. By fixing certain issues with the JSON output from the REST API, the structure of that output has changed slightly. This should not affect any users as it was broken in the first place. To ensure this is the case, please test your implementation in the Release Candidate environment. More information about the Release Candidate environment is described in this document: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-enviro... We look forward to hearing any questions or comments you might have. Regards, Denis Walker Business Analyst RIPE NCC Database Team
Hi, On Mon, Mar 24, 2014 at 02:27:39PM +0100, Denis Walker wrote:
The RIPE Database release 1.72 has now been fully deployed to production.
We would like to point out that, with this release, Webupdates and Syncupdates can only be accessed with HTTPS and not with HTTP. This is to conform to the requirements of using RIPE ACCESS now as an authentication method for updating the RIPE Database. Any update using HTTP will be automatically redirected to HTTPS.
Uh, what? This does not *exactly* meet POLA, and that part of the change was not announced as such - and as it's quite likely that this breaks someone's syncupdate script (why would a syncupdate client be written to handle http->https redirects if all it wants is a single POST?) this really should have been announced before. ... and I'm less than convinced that wanting to have HTTPS *for RIPE ACCESS* is a good reason to force it by surprise on everyone else. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi,
This does not *exactly* meet POLA, and that part of the change was not announced as such - and as it's quite likely that this breaks someone's syncupdate script (why would a syncupdate client be written to handle http->https redirects if all it wants is a single POST?) this really should have been announced before.
I fully agree. Making https mandatory for updates is a change in the public interface to the DB and it should have been announced. Denis: can you gather some stats on how many POSTs are sent over http, get a redirect, and then don't retry over https? It would give a rough estimate of how many scripts can't handle the redirect. Cheers, Sander
Dear colleagues, Let me clarify. Denis was referring to the web forms, that are also named 'syncupdates' and 'webupdates'. The actual syncupdates service did not change. Furthermore, the syncupdates and webupdates web forms were already enforcing https because of sensitive authentication data (e.g. passwords). The only change that happened yesterday was that now we also enforce https on the query form, so that the RIPE Access session token is secured. Sorry for the misunderstanding. Kind regards, Agoston Horvath Senior Software Engineer RIPE NCC On 03/24/2014 09:56 PM, Gert Doering wrote:
Hi,
On Mon, Mar 24, 2014 at 02:27:39PM +0100, Denis Walker wrote:
The RIPE Database release 1.72 has now been fully deployed to production.
We would like to point out that, with this release, Webupdates and Syncupdates can only be accessed with HTTPS and not with HTTP. This is to conform to the requirements of using RIPE ACCESS now as an authentication method for updating the RIPE Database. Any update using HTTP will be automatically redirected to HTTPS.
Uh, what?
This does not *exactly* meet POLA, and that part of the change was not announced as such - and as it's quite likely that this breaks someone's syncupdate script (why would a syncupdate client be written to handle http->https redirects if all it wants is a single POST?) this really should have been announced before.
... and I'm less than convinced that wanting to have HTTPS *for RIPE ACCESS* is a good reason to force it by surprise on everyone else.
Gert Doering -- NetMaster
Hi, On Tue, Mar 25, 2014 at 09:43:21AM +0100, Agoston Horvath wrote:
Denis was referring to the web forms, that are also named 'syncupdates' and 'webupdates'. The actual syncupdates service did not change.
Furthermore, the syncupdates and webupdates web forms were already enforcing https because of sensitive authentication data (e.g. passwords). The only change that happened yesterday was that now we also enforce https on the query form, so that the RIPE Access session token is secured.
Thanks for the clarification. This is far less intrusive than the original mail made me believe, and I think it's a reasonable change which should not have any adverse effects. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, Op 25 mrt. 2014, om 09:55 heeft Gert Doering <gert@space.net> het volgende geschreven:
Hi,
On Tue, Mar 25, 2014 at 09:43:21AM +0100, Agoston Horvath wrote:
Denis was referring to the web forms, that are also named 'syncupdates' and 'webupdates'. The actual syncupdates service did not change.
Furthermore, the syncupdates and webupdates web forms were already enforcing https because of sensitive authentication data (e.g. passwords). The only change that happened yesterday was that now we also enforce https on the query form, so that the RIPE Access session token is secured.
Thanks for the clarification. This is far less intrusive than the original mail made me believe, and I think it's a reasonable change which should not have any adverse effects.
I fully agree. Thanks for the clarification! Sander
On Mon, Mar 24, 2014 at 02:27:39PM +0100, Denis Walker wrote: Dear Denis
The RIPE Database release 1.72 has now been fully deployed to production.
Could you please specify, when the new version of RIPE Database Update Reference Manual will be available online?
We would like to point out that, with this release, Webupdates and Syncupdates can only be accessed with HTTPS and not with HTTP. This is to conform to the requirements of using RIPE ACCESS now as an authentication method for updating the RIPE Database. Any update using HTTP will be automatically redirected to HTTPS.
And this is good example of what I was trying to avoid when we were discussing being over cautious with changing something just a week ago. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear Piotr The new versions of both the Update and Query Reference Manuals in PDF format were available on the www.ripe.net website yesterday. The html version of the new Query Reference Manual is now also available. They both include details of the new SSO auth option. Regards Denis Walker Business Analyst RIPE NCC Database Team On 25/03/2014 08:26, Piotr Strzyzewski wrote:
On Mon, Mar 24, 2014 at 02:27:39PM +0100, Denis Walker wrote:
Dear Denis
The RIPE Database release 1.72 has now been fully deployed to production. Could you please specify, when the new version of RIPE Database Update Reference Manual will be available online?
We would like to point out that, with this release, Webupdates and Syncupdates can only be accessed with HTTPS and not with HTTP. This is to conform to the requirements of using RIPE ACCESS now as an authentication method for updating the RIPE Database. Any update using HTTP will be automatically redirected to HTTPS. And this is good example of what I was trying to avoid when we were discussing being over cautious with changing something just a week ago.
Piotr
On Tue, Mar 25, 2014 at 04:26:35PM +0100, Denis Walker wrote: Dear Denis
The new versions of both the Update and Query Reference Manuals in PDF format were available on the www.ripe.net website yesterday. The html version of the new Query Reference Manual is now also available. They both include details of the new SSO auth option.
Just to excuse myself - the very first sentence in RIPE Database Update Reference Manual (http://www.ripe.net/data-tools/support/documentation/upd-ref-manual) is: "This document describes how to update version 1.71 of the RIPE Database.". I didn't checked the rest of the document. ;-) However, the footers on every page states it is from the version 1.72. Honestly speaking, if this PDF is somehow autogenerated, isn't that obvious to define the version number and then use it everywhere? This is just a rhetorical question. Just to note: The Query Reference Manual (both html and PDF) last updated (according to the webpage and your statement above) on 25 Mar 2014 says: "This document describes how queries work in version 1.68 of the RIPE Database." Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear Piotr, Thanks for pointing out the version mismatches, we’ll update the manuals ASAP. As mentioned earlier we’re currently in the process of improving the documentation. We’re doing this in two phases, first we'll improve our procedures and apply the best practices for documenting software. Once we have the new procedure in place we'll do a major review of the manuals, section by section. Please bear with us until then as this is quite a big project. Kind regards, Johan Åhlén Asst. Manager Database RIPE NCC On 25 Mar 2014, at 21:32, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Tue, Mar 25, 2014 at 04:26:35PM +0100, Denis Walker wrote:
Dear Denis
The new versions of both the Update and Query Reference Manuals in PDF format were available on the www.ripe.net website yesterday. The html version of the new Query Reference Manual is now also available. They both include details of the new SSO auth option.
Just to excuse myself - the very first sentence in RIPE Database Update Reference Manual (http://www.ripe.net/data-tools/support/documentation/upd-ref-manual) is: "This document describes how to update version 1.71 of the RIPE Database.". I didn't checked the rest of the document. ;-) However, the footers on every page states it is from the version 1.72. Honestly speaking, if this PDF is somehow autogenerated, isn't that obvious to define the version number and then use it everywhere? This is just a rhetorical question.
Just to note: The Query Reference Manual (both html and PDF) last updated (according to the webpage and your statement above) on 25 Mar 2014 says: "This document describes how queries work in version 1.68 of the RIPE Database."
Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 26 Mar, Johan Åhlén wrote:
Dear Piotr,
Thanks for pointing out the version mismatches, we’ll update the manuals ASAP.
As mentioned earlier we’re currently in the process of improving the documentation. We’re doing this in two phases, first we'll improve our
Three quick question regarding SSO.. a) I don't see 'SSO' mentioned in the appendix on page 46/47 of the pdf version, shouldn't it be there ? b) if I've added 'sso' auth to a mntner object, can I then only get the unfiltered version by going through the webupdater ? c) is there some "neat" way of sending authentication information to the API and will it use it and in that way let me reach protected elements ? (such as, the auth sso..) (will simple http auth do this?) /Anders
Dear Anders, Thank you for your comments about SSO. I will answer each in turn. a) You are correct about the appendix. We updated section '2.8.1 Authorisation Model' which has the same table as in the Appendix. We will update the Appendix in the next release. In future documentation we will avoid having identical information duplicated in multiple parts of the same document. b) For security reasons we consider the SSO username in the same way as an MD5 password hash. So this is only available in an authenticated way. As we don't yet have authenticated queries it can only be handled by Webupdates. c) Currently there is no “neat” way of authenticating against the RIPE Database RESTful API using your Access SSO account. This kind of authentication actually spans all of the RIPE NCC services that use SSO and provide a REST API. These include the LIR Portal services like the IP Analyser, but also RIPEstat and RIPE Atlas. We could solve this in several ways, for example by providing each RIPE NCC Access account with a unique API access token (thereby tying the authentication to an individual), or by allowing you to set up a "service account", such as OAuth2, that authorises your application to access a certain RIPE NCC API. We’d be quite interested to hear about your use cases, in order to make sure we choose the right implementation. Regards Denis Walker Business Analyst RIPE NCC Database Team On 04/04/2014 15:48, Anders Mundt Due wrote:
On 26 Mar, Johan Åhlén wrote:
Dear Piotr,
Thanks for pointing out the version mismatches, we’ll update the manuals ASAP.
As mentioned earlier we’re currently in the process of improving the documentation. We’re doing this in two phases, first we'll improve our Three quick question regarding SSO..
a) I don't see 'SSO' mentioned in the appendix on page 46/47 of the pdf version, shouldn't it be there ?
b) if I've added 'sso' auth to a mntner object, can I then only get the unfiltered version by going through the webupdater ?
c) is there some "neat" way of sending authentication information to the API and will it use it and in that way let me reach protected elements ? (such as, the auth sso..) (will simple http auth do this?)
/Anders
participants (7)
-
Agoston Horvath -
Anders Mundt Due -
Denis Walker -
Gert Doering -
Johan Åhlén -
Piotr Strzyzewski -
Sander Steffann