[db-wg] Proposal about personalised authorisation

On Mon, Apr 13, 2015 at 06:04:13PM +0200, Tim Bruijnzeels wrote:

Dear DB-WG Members

> On 09 Apr 2015, at 12:44, Aleksi Suhonen <ripe-ml-2015 at ssd.axu.tm> wrote:
> > 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.

We should definitely think about the situation when the person whose
last auth: attribute is going to be removed, is the last auth:
method/attribute in any mntner object.

> 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.

Taking my above comment into account would lead to this situation
described by Tim. Maybe some business rule to prevent random referencing
would help? First idea which pops into my head was the same mechanism
which is used for ROUTE object authorisation:

Second email with the exact copy of the modified MNTNER object with the
authorisation from the PERSON object as a necessary step for referencing
it.

Honestly speaking i'm neither for nor against this idea. ;-)

> >> 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. 

This is also more reasonable for me.

All the best,
Piotr

-- 
gucio -> Piotr Strzyżewski
E-mail: Piotr.Strzyzewski at polsl.pl