[db-wg] Proposal about personalised authorisation

Hi Aleksi,

On 09 Apr 2015, at 12:44, Aleksi Suhonen <ripe-ml-2015 at ssd.axu.tm> wrote:
> 
> Hello,
> 
> I support this proposal in general. I have a few questions below.
> 
> On 04/08/2015 11:07 AM, Tim Bruijnzeels wrote:
>> The RIPE NCC has discussed the concept of personalised authorisation
>> on various occasions, most recently at the DB WG session at RIPE 69.
>> Following discussions and input from the working group we would now
>> like to propose the following additions to the RIPE Database:
>> 
>> = Extend the person object template with "auth:" as an optional,
>> multiple attribute, with all current authentication methods.
>> = Extend the mntner object "auth:" attribute with a new method that
>> allows a reference to a person object that has at least one "auth:"
>> attribute.
> 
> What happens if the all auth: attributes are later removed from a referenced person object? I foresee a potential security default.

We are open to other suggestions of course, and I believe that the WG should have the final say on this..

But.. the way I see this, this should not be a big issue. If all "auth:" attributes are removed from a person object it will become impossible to authenticate as this person. We can issue a warning when a person is updated this way, but ultimately I think it's the responsibility of whoever maintains the person to decide if, and which, auth: attributes should be present.

I do believe it's good to be more restrictive when adding a person to a maintainer, because it's good to prevent a situation where no-one can authenticate. But once a person has been authorised I think it's up to the person to manage their own authentications.

Alternatively we could have business rules that prevent the removal of the last auth: line from a person as long as it's still referenced. But.. I think this may have issues if other people just set up a random maintainer referencing persons in the database to prevent them from removing their auth: attributes.

> 
>> Allowing "auth:" attributes on person objects also allows us to make
>> it easier for users to manage their person object in the RIPE
>> Database in combination with their Single Sign-On (SSO) account on
>> RIPE NCC Access as a single identity.
> 
> I find this idea very convenient. However, I've noticed that some people or some companies prefer to maintain several separate person objects for a single person in different roles. I can't say I approve of this practise entirely, but I suppose we should still have a stated policy of how these cases should be handled. Examples:
> 
> * one SSO account can be coupled with multiple person objects
> * a person with multiple person objects should create multiple SSO accounts, if they all need to be coupled

Of course the WG should have the final say in this case as well.

But I would go for the second option. To me it does not seem unreasonable to demand this one on one coupling for clarity in a security sensitive context. I think it would be good that persons manage their own credentials - e.g. SSO users can also reset their own password and extending this with options to add/remove other credentials to their person object is easy. Associating a single SSO account with multiple person objects could be done, but makes reasoning about this more difficult (not to mention the user interface). I think it would be best if we kept this as simple and clean as possible.

If this does not fit your organisation's needs you could always do what you can currently do on maintainers and (automatically?) manage your staff's credentials directly on the maintainer object, without delegating to persons.

But like I said, this is my personal perspective. We are definitely open to other ideas, and won't implement unless we have a WG mandate.



Kind regards,

Tim Bruijnzeels

Assistant Manager Software Engineering
RIPE NCC


> 
> Yours,
> -- 
> 	Aleksi Suhonen
> 
> 	() ascii ribbon campaign
> 	/\ support plain text e-mail
> 
> -- 
> 	Aleksi Suhonen
> 
> 	() ascii ribbon campaign
> 	/\ support plain text e-mail
>