Personalised authorisation
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-aut... <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.
Hi Denis and all,
On 15 May 2015, at 18:34, denis <ripedenis@yahoo.co.uk> wrote:
Hi Tim and All
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.
I believe that the WG appreciates your efforts on this, and remembers your presentation at RIPE 68: https://ripe68.ripe.net/presentations/299-DB_WG_personalised_Auth_RIPE_68.pd... <https://ripe68.ripe.net/presentations/299-DB_WG_personalised_Auth_RIPE_68.pdf>
The basic idea was to allow authorisation tokens in PERSON objects,
Yes, the important point here is that the credentials are on PERSONs, rather than in one anonymous blob that is today's MNTNER.
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.
There are different opinions on how to refer to authorised persons. The idea to use ROLEs instead of MNTNERs was presented again at RIPE 69, along side with the idea of just allowing to refer to PERSONs from MNTNERs: https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf <https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf> There was no support from the room, nor in informal discussions with working group members, for the option of using ROLEs instead of MNTNERs. While the basic idea sounds attractive there are a lot of problems on closer inspection. MNTNER objects differ from ROLEs in a number of ways that make this, and the ultimate deprecation of MNTNERs difficult. Slides 13 lists what is missing from ROLEs, and would be needed to use them in an mnt-* context. Slide 14 lists what is missing from MNTNERs that would have to be made up, or made optional possibly with business rules enforcing behaviour (e.g. address may still be needed for a *-c referenced role), if remaining MNTNERs were to be converted into ROLEs. And if the latter isn't done, then we would have to live with mnt-* being allowed to refer to either a MNTNER or a ROLE (with special attributes turned on), for a long time, and this is hardly intuitive. There was however support for the basic concept of extending MNTNERs with personalised organisation in a backward compatible way that requires no action from any of the over 50,000 maintainers in the database. The RIPE NCC was tasked with working out and presenting a new plan based on this resulting in the presentation given at RIPE70: https://ripe70.ripe.net/presentations/165-ripe70-pers-auth.pdf <https://ripe70.ripe.net/presentations/165-ripe70-pers-auth.pdf>
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.
In this proposal MNTNER objects remain the specialised security objects that they are today, including features lacking from the normal contact-oriented ROLE object, but personalised authorisation is added with minimal changes to the schema to allow those users that want to make use of this to do so, without forcing any existing maintainer to be modified. This is low hanging fruit. Referring from an object to a MNTNER, and from that MNTNER to a number of authorised PERSONs does not add any layers compared to using a ROLE there instead of the MNTNER. And note that I did not favour using ROLEs in between MNTNERs and authorised PERSONs for this very reason, in response to your comment through chat during the WG session that this should be allowed.
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.
I honestly believe that the now proposed model does all this, the one thing people need to understand is that a MNTNER despite the name 'maintainer' being singular would be allowed to make explicit references to different PERSONs who do the actual maintaining. The MNTNER is like a ROLE for security context. The MNTNER has extra things important to security like: - where do the alerts go? - where do the notifications go? And it's lacking other things relevant to people looking to contact a group of people, but irrelevant when authorising a group of people. Such as: address, email, phone and fax.
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.
cheers Denis Walker Independent Netizen
On 15/05/2015 10:27, Tim Bruijnzeels wrote:
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-aut... <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.
Dear working group, While Tim is away enjoying his new responsibilities as a father, I'm looking after his affairs. :) One open discussion I'd like to come back to is this one, on personalised authorisation. The proposal for personalised authorisation that the RIPE NCC presented at RIPE 70 [1] is aimed at minimising impact, and maximising value for users of the RIPE Database. The approach evolved after receiving negative feedback from the working group on using roles for authorisation at RIPE 69. Our current proposal allows authorisation on person objects for those who want it, through maintainer objects. We believe that this is easily explainable in training courses and user interfaces: objects are are protected by maintainer(s) objects listing a number of authorised persons. Though it has a substantial impact on development resources and the database schema, replacing maintainers with roles is something that could be done later. This is not a prerequisite for having credentials on persons. If the working group agrees, we would like to present an implementation plan to make our proposal a reality. Kind regards, Alex [1] https://ripe70.ripe.net/archives/video/123/
On 16 May 2015, at 18:59, denis <ripedenis@yahoo.co.uk> wrote:
HI Tim
I will contact you off list and hope we can review this together. I will put my full idea to you and see what you think of the whole plan. In the mean time I have added a few comments below.
cheers denis
On 16/05/2015 16:46, Tim Bruijnzeels wrote:
Hi Denis and all,
On 15 May 2015, at 18:34, denis <ripedenis@yahoo.co.uk> wrote:
Hi Tim and All
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.
I believe that the WG appreciates your efforts on this, and remembers your presentation at RIPE 68: https://ripe68.ripe.net/presentations/299-DB_WG_personalised_Auth_RIPE_68.pd...
The basic idea was to allow authorisation tokens in PERSON objects,
Yes, the important point here is that the credentials are on PERSONs, rather than in one anonymous blob that is today's MNTNER.
Agreed, but in your proposal you are missing several key points about how these credentials can be used. I agree on having the option for PERSON objects to be self maintaining, but disagree that you should not allow an organisation to manage the collection of PERSON objects. There are many reasons why an organisation does this. They may want to not allow anyone to use a password and require all staff to use SSO, for example. By maintaining all the PERSON objects they are in control of that. They may want to be able to delete the PERSON object when the person leaves the company. They may want notifications to be centralised. The PERSON objects may only contain corporate information instead of actual personal data to reflect the persons corporate identity.
There was also a major oversight in the original implementation of RPSL. Allowing PERSON object to be directly referenced anywhere has caused so many problems to so many organisation over the last 15 years and continues to do so today. Here is an opportunity to start fixing that as we move forward. By only allowing PERSON objects with "auth:" to be referenced in a ROLE object and then using the ROLE as the maintaining object, not only do we make it more intuitive, but we decouple the direct references to PERSON objects throughout the rest of the database. As time goes on that will prove to be a massive plus.
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.
There are different opinions on how to refer to authorised persons.
You said it yourself that the first 3 hours of a DB training course are spent explaining how to create a PERSON and MNTNER object. That tells a story. If you ask someone who maintains their data they say "I do" or "We do". "I" is a PERSON object. "We" is a ROLE object. This is how people naturally think. Many people simply don't understand what a MNTNER is. It is not even a pronounceable word to a native English speaker. It is abstract and non intuitive. I agree technically there is no difference between using a MNTNER or ROLE object to maintain data. It is just semantics. But there is a world of difference in perception and intuitiveness. The concept of a group of people maintaining data naturally fits a role. I accept we could achieve the same result if we simply renamed the MNTNER as something like AUTH-ROLE and it becomes a special case of a ROLE object. But long term I still favour combining both MNTNER and IRT with ROLE and make this one of the most powerful objects used to manage your data in the DB. (Then people will start to understand why "abuse-c:" was implemented the way it is.)
The idea to use ROLEs instead of MNTNERs was presented again at RIPE 69, along side with the idea of just allowing to refer to PERSONs from MNTNERs: https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf
There was no support from the room, nor in informal discussions with working group members, for the option of using ROLEs instead of MNTNERs. While the basic idea sounds attractive there are a lot of problems on closer inspection. MNTNER objects differ from ROLEs in a number of ways that make this, and the ultimate deprecation of MNTNERs difficult. Slides 13 lists what is missing from ROLEs, and would be needed to use them in an mnt-* context. Slide 14 lists what is missing from MNTNERs that would have to be made up, or made optional possibly with business rules enforcing behaviour (e.g. address may still be needed for a *-c referenced role), if remaining MNTNERs were to be converted into ROLEs. And if the latter isn't done, then we would have to live with mnt-* being allowed to refer to either a MNTNER or a ROLE (with special attributes turned on), for a long time, and this is hardly intuitive.
I think you need to present a full plan rather that just suggest partial ideas. Just asking if we should replace MNTNER with ROLE does not in itself sound like an inspiring move. My proposal to allow this in a parallel track means you can either use the simpler, intuitive method, or stick with the old MNTNER method. I think once people realise the benefits they would move over.
There was however support for the basic concept of extending MNTNERs with personalised organisation in a backward compatible way that requires no action from any of the over 50,000 maintainers in the database. The RIPE NCC was tasked with working out and presenting a new plan based on this resulting in the presentation given at RIPE70: https://ripe70.ripe.net/presentations/165-ripe70-pers-auth.pdf
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.
In this proposal MNTNER objects remain the specialised security objects that they are today, including features lacking from the normal contact-oriented ROLE object, but personalised authorisation is added with minimal changes to the schema to allow those users that want to make use of this to do so, without forcing any existing maintainer to be modified.
My proposal also allows anyone to continue to do what they do now and ignore all the changes.
This is low hanging fruit.
Referring from an object to a MNTNER, and from that MNTNER to a number of authorised PERSONs does not add any layers compared to using a ROLE there instead of the MNTNER. And note that I did not favour using ROLEs in between MNTNERs and authorised PERSONs for this very reason, in response to your comment through chat during the WG session that this should be allowed.
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.
I honestly believe that the now proposed model does all this, the one thing people need to understand is that a MNTNER despite the name 'maintainer' being singular would be allowed to make explicit references to different PERSONs who do the actual maintaining.
The MNTNER is like a ROLE for security context.
The MNTNER has extra things important to security like: - where do the alerts go? - where do the notifications go?
And it's lacking other things relevant to people looking to contact a group of people, but irrelevant when authorising a group of people. Such as: address, email, phone and fax.
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.
cheers Denis Walker Independent Netizen
On 15/05/2015 10:27, Tim Bruijnzeels wrote:
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-aut... 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.
Tim, Denis, other database folks, On Sat, 16 May 2015 16:46:44 +0200 Tim Bruijnzeels <tim@ripe.net> wrote:
The basic idea was to allow authorisation tokens in PERSON objects,
Yes, the important point here is that the credentials are on PERSONs, rather than in one anonymous blob that is today's MNTNER.
Basically, I think of PERSON objects as reflecting contact information about someone in the real world. This has nothing to do with database administration. ROLE objects are a handy layer of indirection so that you can substitute a job function any place you need contact information. Again, nothing to do with database administration. MNTNER objects are the equivalent of a website login. They are a way to authenticate yourself to the database as a database user. They have nothing to do with contact information. ---- This seems pretty straightforward, but it does seem to confuse everyone. Possibly the confusion comes from the name? "Maintainer" doesn't really scream "this is how I authenticate myself, and what authorizations are attached to". I guess I'm fine with adding new authorization mechanisms to the database... compared to our existing mechanisms it doesn't make anything less secure. I do worry about it increasing the confusion rather than making things more straightforward though. :( Cheers, -- Shane
Hi Shane On 18/05/2015 14:43, Shane Kerr wrote:
Tim, Denis, other database folks,
On Sat, 16 May 2015 16:46:44 +0200 Tim Bruijnzeels <tim@ripe.net> wrote:
The basic idea was to allow authorisation tokens in PERSON objects, Yes, the important point here is that the credentials are on PERSONs, rather than in one anonymous blob that is today's MNTNER. Basically, I think of PERSON objects as reflecting contact information about someone in the real world. This has nothing to do with database administration.
ROLE objects are a handy layer of indirection so that you can substitute a job function any place you need contact information. Again, nothing to do with database administration.
I think it is a question of mindset here. You are thinking of the ROLE object in the context it has been implemented within the RIPE Database. Right now it is only used for contacts. As a long established and experienced user of the DB that makes sense to you. It is how you have always seen it and used it. But think about the definition of the word 'role'. " A prescribed or expected behavior associated with a particular position or status in a group or organization." " Jobs or positions that have a specific set of expectations attached to them." So in an organisation, if a group of people carry out a shared or common task, they collectively fulfil a role. When you talk to newbies to the database this is how they tend to think. When they say "we maintain the data" they are actually thinking about a group of people tasked to perform this action collectively....that is a role. This is why it takes so long on the DB training course to teach newbies how to set up a person and maintainer. You have to first sweep away their natural thoughts and then re-educate them into the ways of the MNTNER object. cheers denis
MNTNER objects are the equivalent of a website login. They are a way to authenticate yourself to the database as a database user. They have nothing to do with contact information.
----
This seems pretty straightforward, but it does seem to confuse everyone. Possibly the confusion comes from the name? "Maintainer" doesn't really scream "this is how I authenticate myself, and what authorizations are attached to".
I guess I'm fine with adding new authorization mechanisms to the database... compared to our existing mechanisms it doesn't make anything less secure. I do worry about it increasing the confusion rather than making things more straightforward though. :(
Cheers,
-- Shane
On 15/05/15 09:27, Tim Bruijnzeels wrote:
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-aut... 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.
Of course, those of us with long memories remember the move of authentication from persons to maintainers. Plus ca change.... Nigel
participants (5)
-
Alex Band -
denis -
Nigel Titley -
Shane Kerr -
Tim Bruijnzeels