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.

Reply via email to