[db-wg] anyone using the RIPE Databse MUST now have an SSO account?

Hi Job, group, world

You said you would welcome my thoughts...so here they are...I know the 
data model is a taboo subject. But I hope you and others will actually 
read this email and think about what I said.

It is quite clear that every time I mention it with other matters in any 
email the bit where I mention the data model is cut out of replies, 
never discussed, never even acknowledged. I am starting to believe my 
own conspiratorial theories about why the small group of people who 
'control' the development of the RIPE Database don't want a simplified 
data model so that new members (commercial competitors?) don't need a 
full day course to learn how to make the most basic entries, and still 
get it wrong.

This model was designed way back in the 90s. It has passed it's sell by 
date and is no longer fit for purpose in the 21st century. We are 
constantly dancing round the constraints of this old design. Instead of 
fixing the root cause we keep trying to invent ever more complex high 
level solutions to bolt on top of a bad design.

Security of data and permissions in the RIPE Database is one of these 
areas that is fundamentally broken and cannot be fixed with this data 
model, no matter how many tweaks you make. Who else, but the RIRs, 
publish to the world so much detail about how you manage and secure your 
data? Do you see Google, Apple, Microsoft, Facebook, Twitter, Yahoo, 
Anyone publishing details of their users accounts?

There are basically two types of data in the RIPE Database:

Operational data - the stuff this public registry exists to record and 
publish along with details of who to contact if you have any issue with 
any operational data.

Management data - the details of how you, as an individual or corporate 
entity, manage your operational data in this database. This includes 
details of your security credentials, who has permission to do what, who 
gets notified when things happen, etc.

So the MNTNER object for example is clearly management data. Who, 
outside of your organisation, needs to see anything in your MNTNER 
object? Why do we tell the world that you have 3 passwords, 2 PGP and 4 
SSO accounts managing your data? Why do we tell everyone who has 
permission to create more specific customer operational data in the 
database for your organisation ("mnt-lower:")? Why do we let the world 
know that you have not set up any notifications so you will not notice 
if this data is changed?

A few years ago I did a presentation to Wilfried and Nigel about how 
easy it would be to separate the operational and management data in the 
database so that the whole of the management data could be hidden. User 
accounts for organisations/people who manage the operational data could 
be created to manage security, permissions, notifications, audit trails, 
etc. I even showed how it could be done in a backwards compatible way so 
that no one would be forced to change anything. I even threw in 
significant improvements using inheritance in a backwards compatible way.

But then for a year or so I was not in a position to discuss any 
database issues publicly so the whole idea ground to a halt. If you are 
serious about improving security, the time has come to stop dancing 
round these issues with ever more complex solutions and address the 
problems head on.

All I am proposing is that members/users/interested parties acknowledge 
that the data model is old and could be improved and be willing to 
seriously discuss the possibilities. If you are willing to throw off the 
constraints of this old model many new and improved possibilities open up.

cheers
denis

On 01/12/2015 13:52, Job Snijders wrote:
> Hi Denis, group,
>
> On Tue, Dec 01, 2015 at 01:23:21PM +0100, denis wrote:
>> You now have a situation where updates using the API must be done with a
>> password, updates done with Webupdates must be done with SSO and updates
>> done by email should be done with PGP. So you have actually increased the
>> complexity of the already over complex authorisation model.
>
> This is an excellent summary, I wonder what a good way forward would be.
> Possibly enable PGP authenticated API access? Or introduce a concept of
> "API Keys" which a user can tie to an application and for instance
> restrict which source IP addresses are allowed to use that key? I
> welcome your thoughts on this matter
>
> Kind regards,
>
> Job
>