Proposal about personalised authorisation
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.
Hello, I support this proposal in general. I have a few questions below. On 04/08/2015 11:07 AM, 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.
What happens if the all auth: attributes are later removed from a referenced person object? I foresee a potential security default.
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.
I find this idea very convenient. However, I've noticed that some people or some companies prefer to maintain several separate person objects for a single person in different roles. I can't say I approve of this practise entirely, but I suppose we should still have a stated policy of how these cases should be handled. Examples: * one SSO account can be coupled with multiple person objects * a person with multiple person objects should create multiple SSO accounts, if they all need to be coupled Yours, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail
Hi Aleksi, On 09 Apr 2015, at 12:44, Aleksi Suhonen <ripe-ml-2015@ssd.axu.tm> wrote:
Hello,
I support this proposal in general. I have a few questions below.
On 04/08/2015 11:07 AM, 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.
What happens if the all auth: attributes are later removed from a referenced person object? I foresee a potential security default.
We are open to other suggestions of course, and I believe that the WG should have the final say on this.. But.. the way I see this, this should not be a big issue. If all "auth:" attributes are removed from a person object it will become impossible to authenticate as this person. We can issue a warning when a person is updated this way, but ultimately I think it's the responsibility of whoever maintains the person to decide if, and which, auth: attributes should be present. I do believe it's good to be more restrictive when adding a person to a maintainer, because it's good to prevent a situation where no-one can authenticate. But once a person has been authorised I think it's up to the person to manage their own authentications. Alternatively we could have business rules that prevent the removal of the last auth: line from a person as long as it's still referenced. But.. I think this may have issues if other people just set up a random maintainer referencing persons in the database to prevent them from removing their auth: attributes.
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.
I find this idea very convenient. However, I've noticed that some people or some companies prefer to maintain several separate person objects for a single person in different roles. I can't say I approve of this practise entirely, but I suppose we should still have a stated policy of how these cases should be handled. Examples:
* one SSO account can be coupled with multiple person objects * a person with multiple person objects should create multiple SSO accounts, if they all need to be coupled
Of course the WG should have the final say in this case as well. But I would go for the second option. To me it does not seem unreasonable to demand this one on one coupling for clarity in a security sensitive context. I think it would be good that persons manage their own credentials - e.g. SSO users can also reset their own password and extending this with options to add/remove other credentials to their person object is easy. Associating a single SSO account with multiple person objects could be done, but makes reasoning about this more difficult (not to mention the user interface). I think it would be best if we kept this as simple and clean as possible. If this does not fit your organisation's needs you could always do what you can currently do on maintainers and (automatically?) manage your staff's credentials directly on the maintainer object, without delegating to persons. But like I said, this is my personal perspective. We are definitely open to other ideas, and won't implement unless we have a WG mandate. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
Yours, -- Aleksi Suhonen
() ascii ribbon campaign /\ support plain text e-mail
-- Aleksi Suhonen
() ascii ribbon campaign /\ support plain text e-mail
On Mon, Apr 13, 2015 at 06:04:13PM +0200, Tim Bruijnzeels wrote: Dear DB-WG Members
On 09 Apr 2015, at 12:44, Aleksi Suhonen <ripe-ml-2015@ssd.axu.tm> wrote:
On 04/08/2015 11:07 AM, 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.
What happens if the all auth: attributes are later removed from a referenced person object? I foresee a potential security default.
We are open to other suggestions of course, and I believe that the WG should have the final say on this..
But.. the way I see this, this should not be a big issue. If all "auth:" attributes are removed from a person object it will become impossible to authenticate as this person. We can issue a warning when a person is updated this way, but ultimately I think it's the responsibility of whoever maintains the person to decide if, and which, auth: attributes should be present.
We should definitely think about the situation when the person whose last auth: attribute is going to be removed, is the last auth: method/attribute in any mntner object.
I do believe it's good to be more restrictive when adding a person to a maintainer, because it's good to prevent a situation where no-one can authenticate. But once a person has been authorised I think it's up to the person to manage their own authentications.
Alternatively we could have business rules that prevent the removal of the last auth: line from a person as long as it's still referenced. But.. I think this may have issues if other people just set up a random maintainer referencing persons in the database to prevent them from removing their auth: attributes.
Taking my above comment into account would lead to this situation described by Tim. Maybe some business rule to prevent random referencing would help? First idea which pops into my head was the same mechanism which is used for ROUTE object authorisation: Second email with the exact copy of the modified MNTNER object with the authorisation from the PERSON object as a necessary step for referencing it. Honestly speaking i'm neither for nor against this idea. ;-)
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.
I find this idea very convenient. However, I've noticed that some people or some companies prefer to maintain several separate person objects for a single person in different roles. I can't say I approve of this practise entirely, but I suppose we should still have a stated policy of how these cases should be handled. Examples:
* one SSO account can be coupled with multiple person objects * a person with multiple person objects should create multiple SSO accounts, if they all need to be coupled
Of course the WG should have the final say in this case as well.
But I would go for the second option.
This is also more reasonable for me. All the best, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
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.
participants (4)
-
Aleksi Suhonen -
Job Snijders -
Piotr Strzyzewski -
Tim Bruijnzeels