Dear working group,
Yesterday during the WG session we presented a proposal for implementing
personalised authorisation:
https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf
<https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf>
https://ripe70.ripe.net/archives/video/123
<https://ripe70.ripe.net/archives/video/123>
As recorded in the first cut of the minutes:
> D. Personalised authentication (Tim Bruijnzeels, RIPE NCC)
> (See presentation)
> This will allow one click creation of person objects
> Maintain credentials in one place.
> Allow better auditing.
> Done by extending person object to have multiple optional auth: attribute
> This will ultimately allow existing auth: sso references to be cleaned up
> Last auth: attribute should not be removed from a person object that is
> used in an authorisation context.
Apart from questions about possible additions below, there seemed to be general
approval for the above as an addition to the existing maintainer mechanism.
We would very much like to implement this soon. We are already working on
improving the way users can log in and use the web updates, and manage
maintainers (and who is authorised for them), so having this would be extremely
useful for that effort.
Technically I don't think the above has to depend on further extensions below.
Roles can be added at any time that we consensus on them, and showing audit
logs is a separate effort - building on this.
> Should this be extended to the role object as well? This would involve
> additional business rules but is technically possible.
I understand and fully agree that there is a need to maintain a list of
authorised persons centrally. But in effect a maintainer can be used for this
purpose. Multiple objects can be maintained by the same maintainer, and the
list of persons authorised can then be managed on this single maintainer:
obj1 ---\
---> mnt1 ---> pers1
obj2 ---/ \--> pers2
In other words, just like role objects can group persons in a 'contact'
context, 'maintainers' could group persons in a 'authorisation' context, where
also other things such as "upd-to:" etc can find a home.
So, technically I don't think there is a need to have another role object here:
obj1 ---\
---> mnt1 ---> role1 ---> pers1
obj2 ---/ \--> pers2
Conceptually this can work of course, but it adds some complexity, and things
to resolve:
a) referencing roles from maintainers, and authorised persons from roles
The proposal was to refer to authorised persons from maintainers like this:
auth: person-<nichandle>
Can we resolve this by allowing:
= auth: role-<nichdl> on maintainers
= auth: person-<nichdl> on roles
But no other auth: flavours for now.
Also note that this person is not necessarily an authorisation *contact* for
others. If we follow current practice consistently we would filter this value
for security purpose.
b) business rules regarding auth->role
Suggestion:
- A role can only be added to a maintainer as "auth: role-<nichdl>" if it has
at least one "auth: person-<nichdl>"
- The last "auth: person" can not be removed from a role if it's referenced
anywhere as "auth: role-"
- As before: "auth: person-<nichl>" can only be added if the person has at
least one "auth: <something>"
- As before: the last "auth:" can not be removed from a person if it's
referenced anywhere as "auth: person-"
> It would be useful to record what credential (maintainer) was used to make
> a particular change to an object and this change
> would facilitate this. RV was asked to raise this on the mailing list.
Currently we do know internally which maintainer was used to submit a
successful update, but not which credential. Technically this could be added of
course. And in case of SSO or PGP people can get some idea of which user did
the update. But showing which password hash was used for an update may not be
best security practice.
With authorisation delegated to persons (possibly through roles) we will be
able to give a much more better output. We can refer to the name of the person,
rather than a credential that should be private to that person.
Also note that for any of this we will also need to be sure that the user
viewing this information is authorised to see this. So what we had in mind here
is to show this only on the web interface for logged in users authorised for at
least one mnt-by of the object they are looking at.
