<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="+1"><tt>Hi Tim and All<br>
<br>
Personalised authorisation is an idea I developed over the last
few years. I talked to many people in the community about it at
various RIPE meetings and started to build up support for my
ideas. The basic idea was to allow authorisation tokens in
PERSON objects, group these into ROLE objects and use the ROLE
'instead of' a MNTNER. This is much more intuitive and better
reflects real life business operations. The MNTNER object is an
abstract construct that many people simply don't understand. The
long term goal was to (possibly) eventually deprecate MNTNER
objects. Trying to feed personalised auth into objects via
MNTNERs, even worse through ROLEs and MNTNERs, is not only
adding extra, unnecessary, layers of abstraction but making it
even less intuitive and totally unrelated to real life
situations.<br>
<br>
My original idea was to simplify the auth model and bring it
closer to reality, adding extra, beneficial features, without
losing any of the operational features currently available
through MNTNERs....but without the need to use MNTNERs.
Everything can be done with PERSON and ROLE objects...which
people understand.<br>
<br>
I had this all worked out in my head how to achieve all this,
which is not technically very difficult to implement and not
hard to understand and can be done in parallel with current
MNTNER operation (so no one has to change if they don't want to).
But I never wrote any of this down or presented any detail to
anyone. So I would like to present an alternative option to the
community, along the lines I was thinking and had discussed
briefly with many people. It may take me a week or so to write
it all out and present it as a RIPE Labs article.<br>
<br>
cheers<br>
Denis Walker<br>
Independent Netizen<br>
</tt></font><br>
<div class="moz-cite-prefix">On 15/05/2015 10:27, Tim Bruijnzeels
wrote:<br>
</div>
<blockquote cite="mid:66A34212-F666-4C9A-8C3E-546032855D7A@ripe.net"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=us-ascii">
Dear working group,
<div class=""><br class="">
</div>
<div class="">Yesterday during the WG session we presented a
proposal for implementing personalised authorisation:</div>
<div class=""><a moz-do-not-send="true"
href="https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf"
class="">https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf</a></div>
<div class=""><a moz-do-not-send="true"
href="https://ripe70.ripe.net/archives/video/123" class="">https://ripe70.ripe.net/archives/video/123</a></div>
<div class=""><br class="">
</div>
<div class="">As recorded in the first cut of the minutes:</div>
<blockquote type="cite" class="">
<div class="">
<div class="">D. Personalised authentication (Tim Bruijnzeels,
RIPE NCC)</div>
<div class=""> (See presentation)</div>
<div class=""> This will allow one click creation of person
objects</div>
<div class=""> Maintain credentials in one place.</div>
<div class=""> Allow better auditing.</div>
<div class=""> Done by extending person object to have
multiple optional auth: attribute</div>
<div class=""> This will ultimately allow existing auth: sso
references to be cleaned up</div>
<div class=""> Last auth: attribute should not be removed
from a person object that is used in an authorisation
context.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Apart from questions about possible additions below,
there seemed to be general approval for the above as an addition
to the existing maintainer mechanism.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""> Should this be extended to the role object as
well? This would involve additional business rules but is
technically possible.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class="">obj1 ---\</div>
<div class=""> ---> mnt1 ---> pers1</div>
<div class="">obj2 ---/ \--> pers2</div>
<div class=""> </div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">So, technically I don't think there is a need to
have another role object here:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">obj1 ---\</div>
<div class=""> ---> mnt1 ---> role1
---> pers1</div>
<div class="">obj2 ---/ \-->
pers2</div>
</div>
<div class=""><br class="">
</div>
<div class="">Conceptually this can work of course, but it adds
some complexity, and things to resolve:</div>
<div class=""><br class="">
</div>
<div class="">a) referencing roles from maintainers, and
authorised persons from roles</div>
<div class=""><br class="">
</div>
<div class="">The proposal was to refer to authorised persons
from maintainers like this: auth: person-<nichandle></div>
<div class=""><br class="">
</div>
<div class="">Can we resolve this by allowing:</div>
<div class=""> = auth: role-<nichdl> on maintainers</div>
<div class=""> = auth: person-<nichdl> on roles </div>
<div class=""><br class="">
</div>
<div class="">But no other auth: flavours for now.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">b) business rules regarding auth->role</div>
<div class=""><br class="">
</div>
<div class="">Suggestion:</div>
<div class="">- A role can only be added to a maintainer as
"auth: role-<nichdl>" if it has at least one "auth:
person-<nichdl>"</div>
<div class="">- The last "auth: person" can not be removed from
a role if it's referenced anywhere as "auth: role-"</div>
<div class="">
<div class="">- As before: "auth: person-<nichl>" can
only be added if the person has at least one "auth:
<something>"</div>
<div class="">- As before: the last "auth:" can not be removed
from a person if it's referenced anywhere as "auth: person-"</div>
</div>
</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class=""> It would be useful to record what credential
(maintainer) was used to make a particular change to an
object and this change</div>
<div class=""> would facilitate this. RV was asked to raise
this on the mailing list.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</blockquote>
<br>
</body>
</html>