[db-wg] Proposal about personalised authorisation

Dear DB-WG, RIPE,

The chairs unanimously concluded there is enough support in the group to
implement the 'personalised authorisation' proposal as described below.

No objections have been raised against the concept of personalised
authorisation itself, although one different idea was raised on how to
structure it (roles versus maintainers).

Based on feedback on the mailinglist and in the last DB-WG session at
RIPE70, it is our assessment that the below proposal is an excellent
starting point as it stands. Note that we can always revisit/improve on
the implementation at a later point. 

I ask RIPE NCC to create a proof of concept in the RC environment. The
moment this POC is available we will start banging on it and possibly
suggest futher improvements.

Kind regards,

Job, Piotr, Nigel

On Wed, Apr 08, 2015 at 09:07:58AM +0100, 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.
> 
> There is no requirement to use these extensions, but users that choose
> to  do so can benefit from the following advantages:
> 
> = Currently it is is not always clear who uses the credentials in each
> "auth:" attribute on a mntner. There are two main problems with this.
> First of all this can result in authorisation being given to the wrong
> users, and second this makes it difficult to keep these objects up to
> date. For example it is not easy to remove the password for a specific
> user from a mntner without knowing, or deducing, which password hash
> is theirs. Having explicit references to person objects will make this
> clear.
> = Users who are authorised for multiple mntners will be able to
> maintain their own credentials in one place.
> = Audit logging can be improved. It will become possible to show to
> authorised users of the database which person made which change to
> their object.
> = The security of regaining lost access to a maintainer can be
> improved by letting users of the database reset the credentials on
> their own person object, rather than on a maintainer. Especially when
> the person object is linked with a Single Sign-On account.
> 
> 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.
> 
> To facilitate this we propose the following:
> = Being they are part of the same identity, person objects can only be
> associated with one SSO account, and vice versa.
> = Associated person objects and SSO accounts are automatically kept in
> sync.
> = SSO accounts can associated with new person objects, or existing
> person objects, provided that the user has access to both the SSO
> account and at least one maintainer of the person object.
> = Users will be able to decouple their own SSO account and person
> object.