Improving the RIPE Database Web Interface

You will immediately notice that we have made RIPE NCC Access, our Single Sign-On (SSO) system, the focal point of the new design. The goal is that once you are logged in with your Access account, you can seamlessly use all of our services, from requesting resources to checking RIPE Atlas measurements to making changes in the RIPE Database.

The RIPE Database has supported SSO for several years already, but now we will actively help you migrate from your existing MD5 password. The way this works is that you are now required to log in with your Access account to make any change in the RIPE Database using the web interface. If you don't have an Access account yet, you can create one in just a couple of steps, which will immediately give you the ability to use features like automated password recovery and two-step verification.

Once you are logged in and you edit one of your existing objects, you will be asked to provide your current MD5 password. After your changes have been processed successfully, you will be asked if you want to associate your RIPE NCC Access account with the maintainer. If you agree, you will never have to use your MD5 password again. Any edits will be authorised using the SSO account on your maintainer.

If this is a shared maintainer that is used by your colleagues in the IT department or Network Operations Centre, then they can go through the same steps. Enter the MD5 password once, associate the SSO account and that's it. Alternatively, an authorised person can also add the SSO accounts of their colleagues by adding the attributes in this format:

• auth: SSO < your-sso-email@example.org >

You can add as many SSO accounts to a maintainer as you like, giving you personalised, granular control. Please note that the email addresses of the SSO accounts will not be publicly visible in the RIPE Database. Only authorised users can see them.

We made a clearer separation between personal maintainers that should be used for your own objects, such as your person object, and shared maintainers that you and your colleagues use to manage your resource objects. When you start working at an organisation that manages objects in the RIPE Database, you will first need to create a person object for yourself. This person object should be protected by a maintainer that only you know the credentials for. We created a brand new, simple form for this that replaces the (awkwardly named) New Organisation Startup form. It is now, more accurately, called "Create person and maintainer pair". Once you have completed this form, there is a clear explanation of how to use this maintainer and how it differs from the shared maintainer your organisation in most cases already has.

Another very prominent change is the focus on the maintainer when creating or editing objects. Previously, "mnt-by:" was buried amongst the rest of the attributes but now we lifted it out and made it the first thing you have to choose. Adding additional maintainers is easy with auto-complete and the indication of which authorisation methods are available.

In fact, auto-complete is now deployed throughout the interface, allowing you to easily choose an administrative or technical contact or an organisation name. The same functionality is used to check if a chosen value that needs to be unique (a primary key) is already in use. Lastly, the syntax checking is now much more intuitive, warning you of errors or invalid characters before you submit your object, to help efficiency.

We have also made several improvements to the process of deleting objects from the RIPE Database. For example, if you try to delete an object but you are blocked because it is still referenced by other objects, we now tell you exactly which ones are blocking. In addition, if you delete a person or maintainer that only reference each other, the RIPE Database will prompt you to delete the other object as well, cleaning the RIPE Database from unnecessary clutter.

The last feature we would like to mention is the improved route object creation. For many years it was already possible to submit a route object that did not have all of the authorisations, for example when authorising someone else's ASN that you do not have the credentials for. The RIPE Database will now tell you exactly which authorisation is missing, which maintainer should be used and what the format of the object should be. It will also send a notification email to the party who should supply the additional authorisation that their action is required.

Even though this may seem like a lot of changes, this is only the beginning of the improvements we have planned for the RIPE Database and resource management in general. Over the coming months we will begin to phase out the LIR Portal Object Editors, simplify route object creation even more, especially for out-of-region resources, and start the implementation of personalised authorisation.

Stay tuned for more! We look forward to hearing your feedback.