Re: [db-wg] Idea: magic mntner for all LIR contacts
* Aleksi Suhonen
On 03/12/2018 10:35, Tore Anderson via db-wg wrote:
So I was thinking: is this mandatory and error-prone duplication of work really necessary? Wouldn't it be possible to instead have some kind of magic mntner object that is is kept automatically up to date with «auth: SSO»-attributes for all the LIR user accounts?
I second this idea. Perhaps this should be a different object type tho, to make it clear that editing the magic maintainer by hand will have undesired results. It should be interchangeable with normal maintainers of course, a bit like person objects and role objects are.
Or maybe just expand the existing SSO attribute to accept a RegID. For example: mntner: FOOBAR-MNT auth: SSO no.foobar Which would allow maintenance by all registered user accounts in LIR no.foobar (except for accounts with the «billing» privilege level).
Do you want someone to co-author a PDP on this?
I was hoping that a PDP wouldn't be necessary, to be honest. That is, if the NCC thought it was a good idea they could just go ahead and implement it. (If I recall correctly, the «auth: SSO» functionality was added without there being a community policy demanding it.) That said, if you want to write a proposal to this effect I'd be happy to put my name on it. Tore
Just want to put my 2 cents in, I do think that something like SSO <reg id> would be good but probably another DB auth scheme, like this: auth: SSO-LIR no.foobar I prefer this so that it is just clear that it is a different thing. Kind regards, Cynthia Revström On 2019-01-07 09:31, Tore Anderson via db-wg wrote:
* Aleksi Suhonen
On 03/12/2018 10:35, Tore Anderson via db-wg wrote:
So I was thinking: is this mandatory and error-prone duplication of work really necessary? Wouldn't it be possible to instead have some kind of magic mntner object that is is kept automatically up to date with «auth: SSO»-attributes for all the LIR user accounts? I second this idea. Perhaps this should be a different object type tho, to make it clear that editing the magic maintainer by hand will have undesired results. It should be interchangeable with normal maintainers of course, a bit like person objects and role objects are. Or maybe just expand the existing SSO attribute to accept a RegID. For example:
mntner: FOOBAR-MNT auth: SSO no.foobar
Which would allow maintenance by all registered user accounts in LIR no.foobar (except for accounts with the «billing» privilege level).
Do you want someone to co-author a PDP on this? I was hoping that a PDP wouldn't be necessary, to be honest. That is, if the NCC thought it was a good idea they could just go ahead and implement it. (If I recall correctly, the «auth: SSO» functionality was added without there being a community policy demanding it.)
That said, if you want to write a proposal to this effect I'd be happy to put my name on it.
Tore
* Cynthia Revström via db-wg
I do think that something like SSO <reg id> would be good but probably another DB auth scheme, like this:
auth: SSO-LIR no.foobar
I prefer this so that it is just clear that it is a different thing.
No objections from me. I'm good with any semantics as long as it is something I can set once and then forget about forever. Tore
Tore Anderson via db-wg wrote on 07/01/2019 09:32:
* Cynthia Revström via db-wg
I do think that something like SSO <reg id> would be good but probably another DB auth scheme, like this:
auth: SSO-LIR no.foobar
I prefer this so that it is just clear that it is a different thing.
No objections from me. I'm good with any semantics as long as it is something I can set once and then forget about forever.
This is a sensible idea. I'd like to see it, or something equivalent, implemented. Nick
On Mon, Jan 07, 2019 at 09:33:58AM +0000, Nick Hilliard via db-wg wrote:
Tore Anderson via db-wg wrote on 07/01/2019 09:32:
* Cynthia Revström via db-wg
I do think that something like SSO <reg id> would be good but probably another DB auth scheme, like this:
auth: SSO-LIR no.foobar
I prefer this so that it is just clear that it is a different thing.
No objections from me. I'm good with any semantics as long as it is something I can set once and then forget about forever.
This is a sensible idea. I'd like to see it, or something equivalent, implemented.
+1 Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
Hi, On Mon, Jan 07, 2019 at 09:33:58AM +0000, Nick Hilliard via db-wg wrote:
auth: SSO-LIR no.foobar
This is a sensible idea. I'd like to see it, or something equivalent, implemented.
+1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi,
Op 7 jan. 2019, om 10:33 heeft Nick Hilliard via db-wg <db-wg@ripe.net> het volgende geschreven:
Tore Anderson via db-wg wrote on 07/01/2019 09:32:
* Cynthia Revström via db-wg
I do think that something like SSO <reg id> would be good but probably another DB auth scheme, like this: auth: SSO-LIR no.foobar I prefer this so that it is just clear that it is a different thing. No objections from me. I'm good with any semantics as long as it is something I can set once and then forget about forever.
This is a sensible idea. I'd like to see it, or something equivalent, implemented.
+1 from me. Indeed very sensible. Sander
On Mon, Jan 07, 2019 at 09:31:58AM +0100, Tore Anderson via db-wg wrote: Tore,
Do you want someone to co-author a PDP on this?
I was hoping that a PDP wouldn't be necessary, to be honest. That is, if the NCC thought it was a good idea they could just go ahead and implement it. (If I recall correctly, the ??auth: SSO?? functionality was added without there being a community policy demanding it.)
That said, if you want to write a proposal to this effect I'd be happy to put my name on it.
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI. Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
* Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI.
Thanks for the pointer! Chairs (cc-ed), could we have an NWI for this? Rough problem statement for the kickstart phase follows: There is currently no way to automatically sync the «auth: SSO x@y» attributes for a maintainer object with the list of (non-billing) users associated with an LIR. This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places). Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question. It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well. Tore
Hi Tore Just to clarify a point here. Are you suggesting that for all LIRs, all listed LIR (non-billing) administrators should be able to manage all the LIR's database objects that will all be maintained by this one 'magic' MNTNER object as "mnt-by:", "mnt-lower:", "mnt-routes"? If any of the 'all' in that statement don't apply then can we be clearer on the use case for this MNTNER object? cheersdenisco-chair DB-WG From: Tore Anderson via db-wg <db-wg@ripe.net> To: Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> Cc: db-wg-chairs@ripe.net; Aleksi Suhonen <Aleksi.Suhonen@axu.tm>; db-wg@ripe.net Sent: Monday, 7 January 2019, 10:25 Subject: Re: [db-wg] Idea: magic mntner for all LIR contacts * Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI.
Thanks for the pointer! Chairs (cc-ed), could we have an NWI for this? Rough problem statement for the kickstart phase follows: There is currently no way to automatically sync the «auth: SSO x@y» attributes for a maintainer object with the list of (non-billing) users associated with an LIR. This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places). Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question. It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well. Tore
Hi Denis, I think the current main suggestion is to add a new DB auth scheme, such as "auth: SSO-LIR no.foobar" that includes all the SSO accounts linked to the LIR except for Billing accounts. Kind regards, Cynthia Revström On 2019-01-07 11:20, denis walker via db-wg wrote:
Hi Tore
Just to clarify a point here. Are you suggesting that for all LIRs, all listed LIR (non-billing) administrators should be able to manage all the LIR's database objects that will all be maintained by this one 'magic' MNTNER object as "mnt-by:", "mnt-lower:", "mnt-routes"?
If any of the 'all' in that statement don't apply then can we be clearer on the use case for this MNTNER object?
cheers denis co-chair DB-WG
------------------------------------------------------------------------ *From:* Tore Anderson via db-wg <db-wg@ripe.net> *To:* Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> *Cc:* db-wg-chairs@ripe.net; Aleksi Suhonen <Aleksi.Suhonen@axu.tm>; db-wg@ripe.net *Sent:* Monday, 7 January 2019, 10:25 *Subject:* Re: [db-wg] Idea: magic mntner for all LIR contacts
* Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI.
Thanks for the pointer!
Chairs (cc-ed), could we have an NWI for this?
Rough problem statement for the kickstart phase follows:
There is currently no way to automatically sync the «auth: SSO x@y <mailto:x@y>» attributes for a maintainer object with the list of (non-billing) users associated with an LIR.
This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places).
Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question.
It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well.
Tore
Cynthia Revström via db-wg wrote on 07/01/2019 10:27:
I think the current main suggestion is to add a new DB auth scheme, such as "auth: SSO-LIR no.foobar" that includes all the SSO accounts linked to the LIR except for Billing accounts.
Denis is just pointing out that it may not be advisable to statically tie this into a potentially inflexible mechanism like the main LIR authentication list. You can be guaranteed that if this were done, someone would come along with a credible reason to have a LIR account with admin control over portal stuff, but not direct DB control of a specific object or set of objects. One possible option to work around this limitation would be to create a new db object type, "sso-set", which could contain a list of SSO account names, e.g.: sso-set: FOOBAR1-RIPE descr: List of SSO tokens for no.foobar members: foo@example.com members: bar@example.org mnt-by: TBD1-RIPE source: RIPE Each LIR would be able to define sso-sets with arbitrary contents and tie them to objects, e.g. like this: auth: SSO-SET FOOBAR1-RIPE There would need to be some thought put into how to handle mnt-by: for the sso-set object (quis custodiet ipsos custodes)? Nick
I think the point of this maintainer issue was that if you removed someone from the LIR auth list, they would also get removed from the DB maintainer. I don't think that SSO-LIR should be the standard, but it should be an option in my opinion. Because while what you are describing could be an issue, I think it could be a bigger issue to forget to remove someone from the SSO in the maintainer. Kind regards, Cynthia Revström On 2019-01-07 11:48, Nick Hilliard wrote:
Cynthia Revström via db-wg wrote on 07/01/2019 10:27:
I think the current main suggestion is to add a new DB auth scheme, such as "auth: SSO-LIR no.foobar" that includes all the SSO accounts linked to the LIR except for Billing accounts.
Denis is just pointing out that it may not be advisable to statically tie this into a potentially inflexible mechanism like the main LIR authentication list. You can be guaranteed that if this were done, someone would come along with a credible reason to have a LIR account with admin control over portal stuff, but not direct DB control of a specific object or set of objects.
One possible option to work around this limitation would be to create a new db object type, "sso-set", which could contain a list of SSO account names, e.g.:
sso-set: FOOBAR1-RIPE descr: List of SSO tokens for no.foobar members: foo@example.com members: bar@example.org mnt-by: TBD1-RIPE source: RIPE
Each LIR would be able to define sso-sets with arbitrary contents and tie them to objects, e.g. like this:
auth: SSO-SET FOOBAR1-RIPE
There would need to be some thought put into how to handle mnt-by: for the sso-set object (quis custodiet ipsos custodes)?
Nick
Hi,
I think the point of this maintainer issue was that if you removed someone from the LIR auth list, they would also get removed from the DB maintainer. I don't think that SSO-LIR should be the standard, but it should be an option in my opinion.
Agree. For many small LIRs there aren't that many roles in the organisation that require different permissions. Fr those (like mine) having an easy way to sync a LIR's SSO accounts to a MNTNER would be very helpful. More complex schemes can already be implemented with the current auth: SSO scheme. I'd like to see this auth: SSO-LIR scheme to simplify the uncomplicated end of the spectrum :) Cheers, Sander
So maybe we are thinking of something like this: A MNTNER object that is created by the RIPE NCC and perhaps jointly maintained by the RIPE NCC and the LIR, that is created when a new LIR is established and includes the SSO auth of all listed (non-billing) LIR contacts. Each time a (non-billing) contact is added or removed from the LIR account the appropriate SSO auth is automatically added or removed from this MNTNER object. Automatic changes are only made to the MNTNER object when a change is made to the LIR user contact list, but not constantly synced. Then the LIR can optionally choose to manually remove any of the contacts from the MNTNER object and it won't automatically be re-synced. The LIR can choose if, when, where and how to use this MNTNER object. OR: A new auth option auth: SSO-LIR no.foobar where SSO-LIR is automatically expanded to include all the (selected) listed LIR (non-billing) contacts for no.foobar. There could be an option in the LIR portal to mark/flag which of the LIR contacts are to be included in the expanded list. The LIR can choose if, when, where and how to use this auth option. cheersdenisco-chair DB-WG From: Cynthia Revström via db-wg <db-wg@ripe.net> To: Nick Hilliard <nick@foobar.org> Cc: db-wg@ripe.net Sent: Monday, 7 January 2019, 11:54 Subject: Re: [db-wg] Idea: magic mntner for all LIR contacts I think the point of this maintainer issue was that if you removed someone from the LIR auth list, they would also get removed from the DB maintainer. I don't think that SSO-LIR should be the standard, but it should be an option in my opinion. Because while what you are describing could be an issue, I think it could be a bigger issue to forget to remove someone from the SSO in the maintainer. Kind regards, Cynthia Revström On 2019-01-07 11:48, Nick Hilliard wrote:
Cynthia Revström via db-wg wrote on 07/01/2019 10:27:
I think the current main suggestion is to add a new DB auth scheme, such as "auth: SSO-LIR no.foobar" that includes all the SSO accounts linked to the LIR except for Billing accounts.
Denis is just pointing out that it may not be advisable to statically tie this into a potentially inflexible mechanism like the main LIR authentication list. You can be guaranteed that if this were done, someone would come along with a credible reason to have a LIR account with admin control over portal stuff, but not direct DB control of a specific object or set of objects.
One possible option to work around this limitation would be to create a new db object type, "sso-set", which could contain a list of SSO account names, e.g.:
sso-set: FOOBAR1-RIPE descr: List of SSO tokens for no.foobar members: foo@example.com members: bar@example.org mnt-by: TBD1-RIPE source: RIPE
Each LIR would be able to define sso-sets with arbitrary contents and tie them to objects, e.g. like this:
auth: SSO-SET FOOBAR1-RIPE
There would need to be some thought put into how to handle mnt-by: for the sso-set object (quis custodiet ipsos custodes)?
Nick
Hello Denis, I think we are (or at least I am) currently thinking of the second option. Kind regards, Cynthia Revström On 2019-01-07 12:34, denis walker wrote:
So maybe we are thinking of something like this:
A MNTNER object that is created by the RIPE NCC and perhaps jointly maintained by the RIPE NCC and the LIR, that is created when a new LIR is established and includes the SSO auth of all listed (non-billing) LIR contacts.
Each time a (non-billing) contact is added or removed from the LIR account the appropriate SSO auth is automatically added or removed from this MNTNER object.
Automatic changes are only made to the MNTNER object when a change is made to the LIR user contact list, but not constantly synced. Then the LIR can optionally choose to manually remove any of the contacts from the MNTNER object and it won't automatically be re-synced.
The LIR can choose if, when, where and how to use this MNTNER object.
OR:
A new auth option auth: SSO-LIR no.foobar
where SSO-LIR is automatically expanded to include all the (selected) listed LIR (non-billing) contacts for no.foobar. There could be an option in the LIR portal to mark/flag which of the LIR contacts are to be included in the expanded list.
The LIR can choose if, when, where and how to use this auth option.
cheers denis co-chair DB-WG
------------------------------------------------------------------------ *From:* Cynthia Revström via db-wg <db-wg@ripe.net> *To:* Nick Hilliard <nick@foobar.org> *Cc:* db-wg@ripe.net *Sent:* Monday, 7 January 2019, 11:54 *Subject:* Re: [db-wg] Idea: magic mntner for all LIR contacts
I think the point of this maintainer issue was that if you removed someone from the LIR auth list, they would also get removed from the DB maintainer. I don't think that SSO-LIR should be the standard, but it should be an option in my opinion.
Because while what you are describing could be an issue, I think it could be a bigger issue to forget to remove someone from the SSO in the maintainer.
Kind regards, Cynthia Revström
On 2019-01-07 11:48, Nick Hilliard wrote:
Cynthia Revström via db-wg wrote on 07/01/2019 10:27:
I think the current main suggestion is to add a new DB auth scheme, such as "auth: SSO-LIR no.foobar" that includes all the SSO accounts linked to the LIR except for Billing accounts.
Denis is just pointing out that it may not be advisable to statically tie this into a potentially inflexible mechanism like the main LIR authentication list. You can be guaranteed that if this were done, someone would come along with a credible reason to have a LIR account with admin control over portal stuff, but not direct DB control of a specific object or set of objects.
One possible option to work around this limitation would be to create a new db object type, "sso-set", which could contain a list of SSO account names, e.g.:
sso-set: FOOBAR1-RIPE descr: List of SSO tokens for no.foobar members: foo@example.com <mailto:foo@example.com> members: bar@example.org <mailto:bar@example.org> mnt-by: TBD1-RIPE source: RIPE
Each LIR would be able to define sso-sets with arbitrary contents and tie them to objects, e.g. like this:
auth: SSO-SET FOOBAR1-RIPE
There would need to be some thought put into how to handle mnt-by: for the sso-set object (quis custodiet ipsos custodes)?
Nick
On Mon, Jan 07, 2019 at 11:34:49AM +0000, denis walker wrote:
Automatic changes are only made to the MNTNER object when a change is made to the LIR user contact list, but not constantly synced. Then the LIR can optionally choose to manually remove any of the contacts from the MNTNER object and it won't automatically be re-synced.
This is imho very bad idea. After short while someone will be wondering what has happened to the MNTNER object and why some of the LIR contacts are not there. Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
I do think that the better option has to be the SSO-LIR scheme rather then a 'magic' maintainer, it would look cleaner/easier to understand. Kind regards, Cynthia Revström On 2019-01-07 12:47, Piotr Strzyzewski wrote:
On Mon, Jan 07, 2019 at 11:34:49AM +0000, denis walker wrote:
Automatic changes are only made to the MNTNER object when a change is made to the LIR user contact list, but not constantly synced. Then the LIR can optionally choose to manually remove any of the contacts from the MNTNER object and it won't automatically be re-synced. This is imho very bad idea. After short while someone will be wondering what has happened to the MNTNER object and why some of the LIR contacts are not there.
Piotr
* denis walker via db-wg
A MNTNER object that is created by the RIPE NCC and perhaps jointly maintained by the RIPE NCC and the LIR, that is created when a new LIR is established and includes the SSO auth of all listed (non-billing) LIR contacts.
Each time a (non-billing) contact is added or removed from the LIR account the appropriate SSO auth is automatically added or removed from this MNTNER object.
Automatic changes are only made to the MNTNER object when a change is made to the LIR user contact list, but not constantly synced. Then the LIR can optionally choose to manually remove any of the contacts from the MNTNER object and it won't automatically be re-synced.
The LIR can choose if, when, where and how to use this MNTNER object.
That would solve my problem, although I do think that it is simpler and more intuitive if this object is 100% managed by the NCC and therefore is not allowed to go out of sync with the user list in the LIR portal. That way you don't have to consider corner cases such as: 1) foo@bar was added to LIR account and therefore automatically to magic maintainer object too 2) foo@bar was manually removed from magic maintainer object 3) foo@bar was removed from LIR account user list (or changed to billing-only) 4) foo@bar was added back to LIR account user list (or changed back to regular/admin) ...should foo@bar now be re-added to the magic maintainer or not?
A new auth option auth: SSO-LIR no.foobar
where SSO-LIR is automatically expanded to include all the (selected) listed LIR (non-billing) contacts for no.foobar. There could be an option in the LIR portal to mark/flag which of the LIR contacts are to be included in the expanded list.
The LIR can choose if, when, where and how to use this auth option.
That would indeed solve my problem too. I would personally have no need for the mark/flag, though. In my case, any colleague with «Regular» access level or above in the portal (defined as «The Operator will have full access to RIPE NCC services») should be authorised to maintain our database objects. Tore
Hi, On Mon, Jan 07, 2019 at 10:48:09AM +0000, Nick Hilliard via db-wg wrote:
One possible option to work around this limitation would be to create a new db object type, "sso-set", which could contain a list of SSO account names, e.g.:
sso-set: FOOBAR1-RIPE descr: List of SSO tokens for no.foobar members: foo@example.com members: bar@example.org mnt-by: TBD1-RIPE source: RIPE
Each LIR would be able to define sso-sets with arbitrary contents and tie them to objects, e.g. like this:
auth: SSO-SET FOOBAR1-RIPE
There would need to be some thought put into how to handle mnt-by: for the sso-set object (quis custodiet ipsos custodes)?
Not sure how that is better than what we have today? Tore's problem statement is "I have added a user to the LIR portal and I do not want to subsequently update a database object to give DB privs to said user" - SSO-SET won't help with that problem statement. Your case would help a LIR that has umpteen different mntner: objects that should all use the same (sub-)set of SSO credentials, and you want to update them in a single place. While I can see that use case, it's solving a different problem. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Mon, Jan 07, 2019 at 12:00:14PM +0100, Gert Doering via db-wg wrote: Hi
While I can see that use case, it's solving a different problem.
Maybe one new role or checkbox added to the existing user roles in LIR Portal would be a solution. This role or checkbox could indicate that the user is member of SSO-LIR "group". Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
Hi
Maybe one new role or checkbox added to the existing user roles in LIR Portal would be a solution. This role or checkbox could indicate that the user is member of SSO-LIR "group".
I do like this idea with a checkbox, it gives flexibility while still achieving the goal. Something like the screenshot here: https://cdn.cynthia.re/upload/firefox_2019-01-07_12-31-00.png would be what I am imagining. Kind regards, Cynthia Revström
Cynthia Revström via db-wg wrote on 07/01/2019 11:31:
I do like this idea with a checkbox, it gives flexibility while still achieving the goal.
it will work until the point that your LIR is large enough that you need segmented / group access control for your DB objects. Then it will break. Nick
(sorry I am really failing at this today, re-sent due to sending it to Nick by accident the first time) Well yes, but I think this feature could be aimed at smaller LIRs with this simple need and larger LIRs with other needs will have to do it the current way with multiple auth SSO attributes. Kind regards, Cynthia Revström On 2019-01-07 12:34, Nick Hilliard wrote:
Cynthia Revström via db-wg wrote on 07/01/2019 11:31:
I do like this idea with a checkbox, it gives flexibility while still achieving the goal.
it will work until the point that your LIR is large enough that you need segmented / group access control for your DB objects. Then it will break.
Nick
then we can get even more flexible if the LIR portal allows you to define set names for lists of SSO auths. So instead of just flagging a contact to be included in 'the' list of expanded SSO auths, you can add a csl of list names in the portal. Then you can have all your contacts defined in any combination of multiple lists that you choose. eg,Person 1 | List1,List3Person 2 | List1Person 3 | List2Person 4 | List1, List2 Person 5 | List3 then define the new auth asauth: SSO-LIR no.foobar.List3 which will be automatically expanded to those contacts defined as being in List3 cheersdenisco-chair DB-WG (Piotr we seem to be thinking along the same lines, each time I type something I see you have just posted the same idea just before me :) ) From: Cynthia Revström via db-wg <db-wg@ripe.net> To: Nick Hilliard <nick@foobar.org> Cc: db-wg@ripe.net Sent: Monday, 7 January 2019, 12:37 Subject: Re: [db-wg] Idea: magic mntner for all LIR contacts (sorry I am really failing at this today, re-sent due to sending it to Nick by accident the first time) Well yes, but I think this feature could be aimed at smaller LIRs with this simple need and larger LIRs with other needs will have to do it the current way with multiple auth SSO attributes. Kind regards, Cynthia Revström On 2019-01-07 12:34, Nick Hilliard wrote:
Cynthia Revström via db-wg wrote on 07/01/2019 11:31:
I do like this idea with a checkbox, it gives flexibility while still achieving the goal.
it will work until the point that your LIR is large enough that you need segmented / group access control for your DB objects. Then it will break.
Nick
Hello On 2019-01-07 12:51, denis walker wrote:
Person 1 | List1,List3 Person 2 | List1 Person 3 | List2 Person 4 | List1, List2 Person 5 | List3
then define the new auth as auth: SSO-LIR no.foobar.List3 which will be automatically expanded to those contacts defined as being in List3
This but with an option to just do: auth: SSO-LIR no.foobar to include all accounts in that LIR. Kind regards, Cynthia Revström
* denis walker via db-wg
then we can get even more flexible if the LIR portal allows you to define set names for lists of SSO auths. So instead of just flagging a contact to be included in 'the' list of expanded SSO auths, you can add a csl of list names in the portal. Then you can have all your contacts defined in any combination of multiple lists that you choose.
eg, Person 1 | List1,List3 Person 2 | List1 Person 3 | List2 Person 4 | List1, List2 Person 5 | List3
then define the new auth as auth: SSO-LIR no.foobar.List3 which will be automatically expanded to those contacts defined as being in List3
This would certainly solve my problem too (especially if there's an implicit «all» group available), but I am somewhat worried about feature creep here, as this would require changes / new features in the RIPE NCC Access / LIR Portal applications. My original proposal would only require reading information already stored in those applications. I'm not in a position to estimate the amount of additional work needed for this, just keep in mind the saying «perfect is the enemy of good». Tore
On one hand I do not want a feature creep thing either but I also want something that will work for larger LIRs too while we are at it. Could we get someone who knows about the website code to comment on the feasibility of this? Kind regards, Cynthia Revström On 2019-01-07 13:21, Tore Anderson wrote:
This would certainly solve my problem too (especially if there's an implicit «all» group available), but I am somewhat worried about feature creep here, as this would require changes / new features in the RIPE NCC Access / LIR Portal applications.
My original proposal would only require reading information already stored in those applications.
I'm not in a position to estimate the amount of additional work needed for this, just keep in mind the saying «perfect is the enemy of good».
I suspect the RIPE NCC can't give an answer in 5 minutes as to how long it would take to implement such a feature. So I think it is better to decide what people really want and then ask the NCC to estimate the work required as part of the NWI process. Given that you are all managing with the system as it is right now, if it takes a little bit longer to implement a slightly more complex feature that benefits all LIRs, that may be better than going for a simple feature that only benefits small LIRs. But of course that depends if the bigger LIRs think this would be a useful feature for them to use as well. cheersdenisco-chair DB-WG From: Cynthia Revström <me@cynthia.re> To: Tore Anderson <tore@fud.no>; denis walker <ripedenis@yahoo.co.uk>; Nick Hilliard <nick@foobar.org>; Piotr Strzyzewski <piotr.strzyzewski@polsl.pl> Cc: "db-wg@ripe.net" <db-wg@ripe.net> Sent: Monday, 7 January 2019, 13:26 Subject: Re: [db-wg] Idea: magic mntner for all LIR contacts On one hand I do not want a feature creep thing either but I also want something that will work for larger LIRs too while we are at it. Could we get someone who knows about the website code to comment on the feasibility of this? Kind regards, Cynthia Revström On 2019-01-07 13:21, Tore Anderson wrote:
This would certainly solve my problem too (especially if there's an implicit «all» group available), but I am somewhat worried about feature creep here, as this would require changes / new features in the RIPE NCC Access / LIR Portal applications.
My original proposal would only require reading information already stored in those applications.
I'm not in a position to estimate the amount of additional work needed for this, just keep in mind the saying «perfect is the enemy of good».
I have to agree with this, so if I have understood everything what we are currently looking at is something like: mntner: TEST1-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar mnt-by: TEST1-MNT source: RIPE mntner: TEST2-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar group1 mnt-by: TEST2-MNT source: RIPE mntner: TEST3-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar group2 mnt-by: TEST3-MNT source: RIPE Person 1 -> Access to TEST1-MNT Person 2 | group1 -> Access to TEST1-MNT, and TEST2-MNT Person 3 | group1, group2 -> Access to TEST1-MNT, TEST2-MNT, and TEST3-MNT Is this what all of you are also thinking of? Kind regards, Cynthia Revström On 2019-01-07 13:35, denis walker wrote:
I suspect the RIPE NCC can't give an answer in 5 minutes as to how long it would take to implement such a feature. So I think it is better to decide what people really want and then ask the NCC to estimate the work required as part of the NWI process.
Given that you are all managing with the system as it is right now, if it takes a little bit longer to implement a slightly more complex feature that benefits all LIRs, that may be better than going for a simple feature that only benefits small LIRs.
But of course that depends if the bigger LIRs think this would be a useful feature for them to use as well.
cheers denis co-chair DB-WG
------------------------------------------------------------------------ *From:* Cynthia Revström <me@cynthia.re> *To:* Tore Anderson <tore@fud.no>; denis walker <ripedenis@yahoo.co.uk>; Nick Hilliard <nick@foobar.org>; Piotr Strzyzewski <piotr.strzyzewski@polsl.pl> *Cc:* "db-wg@ripe.net" <db-wg@ripe.net> *Sent:* Monday, 7 January 2019, 13:26 *Subject:* Re: [db-wg] Idea: magic mntner for all LIR contacts
On one hand I do not want a feature creep thing either but I also want something that will work for larger LIRs too while we are at it.
Could we get someone who knows about the website code to comment on the feasibility of this?
Kind regards, Cynthia Revström
On 2019-01-07 13:21, Tore Anderson wrote:
This would certainly solve my problem too (especially if there's an implicit «all» group available), but I am somewhat worried about feature creep here, as this would require changes / new features in the RIPE NCC Access / LIR Portal applications.
My original proposal would only require reading information already stored in those applications.
I'm not in a position to estimate the amount of additional work needed for this, just keep in mind the saying «perfect is the enemy of good».
* Cynthia Revström via db-wg
I have to agree with this, so if I have understood everything what we are currently looking at is something like:
mntner: TEST1-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar mnt-by: TEST1-MNT source: RIPE
mntner: TEST2-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar group1 mnt-by: TEST2-MNT source: RIPE
mntner: TEST3-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar group2 mnt-by: TEST3-MNT source: RIPE
Person 1 -> Access to TEST1-MNT Person 2 | group1 -> Access to TEST1-MNT, and TEST2-MNT Person 3 | group1, group2 -> Access to TEST1-MNT, TEST2-MNT, and TEST3-MNT
Is this what all of you are also thinking of?
The TEST1-MNT part of would cater for my use case. The TEST2-MNT and TEST3-MNT parts of it are irrelevant to me (but I have no objections to such functionality per se). In any case I would like to second Nick's comment about not being too prescriptive about how it ends up being implemented, though. As long as the basic desired functionality is provided for, I don't really care about how it ends up looking. The product owners and developers are in a better position to make those calls and I think we trust them to come up with the best solution. Tore
Hi Tore,
I have to agree with this, so if I have understood everything what we are currently looking at is something like:
mntner: TEST1-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar mnt-by: TEST1-MNT source: RIPE
mntner: TEST2-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar group1 mnt-by: TEST2-MNT source: RIPE
mntner: TEST3-MNT admin-c: TEST-RIPE auth: SSO-LIR no.foobar group2 mnt-by: TEST3-MNT source: RIPE
Person 1 -> Access to TEST1-MNT Person 2 | group1 -> Access to TEST1-MNT, and TEST2-MNT Person 3 | group1, group2 -> Access to TEST1-MNT, TEST2-MNT, and TEST3-MNT
Is this what all of you are also thinking of?
The TEST1-MNT part of would cater for my use case.
The TEST2-MNT and TEST3-MNT parts of it are irrelevant to me (but I have no objections to such functionality per se).
In any case I would like to second Nick's comment about not being too prescriptive about how it ends up being implemented, though. As long as the basic desired functionality is provided for, I don't really care about how it ends up looking. The product owners and developers are in a better position to make those calls and I think we trust them to come up with the best solution.
+1 to all of the above. Same use-case, same feeling about Nick's comment :) Sander
denis walker wrote on 07/01/2019 11:51:
then we can get even more flexible if the LIR portal allows you to define set names for lists of SSO auths. So instead of just flagging a contact to be included in 'the' list of expanded SSO auths, you can add a csl of list names in the portal. Then you can have all your contacts defined in any combination of multiple lists that you choose.
rather than getting too prescriptive about how we think this ought to be implemented, it may be a better idea to think about what we need as a final outcome and let the RIPE NCC people do the design + implementation. At the moment, there seems to be some convergence towards: 1. enabling LIRs to define SSO authentication groups, and that each mntner object can be associated with any particular authentication group. 2. providing configuration access to SSO authentication groups via the portal UI. Nick
On Mon, Jan 07, 2019 at 11:34:17AM +0000, Nick Hilliard via db-wg wrote:
Cynthia Revström via db-wg wrote on 07/01/2019 11:31:
I do like this idea with a checkbox, it gives flexibility while still achieving the goal.
it will work until the point that your LIR is large enough that you need segmented / group access control for your DB objects. Then it will break.
Which could be easily resolved with creating and naming SSO-LIR groups in LIR Portal and using them like that: auth: SSO-LIR no.foobar.group1 or auth: SSO-LIR no.foobar group1 Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
On 2019-01-07 12:43, Piotr Strzyzewski wrote:
On Mon, Jan 07, 2019 at 11:34:17AM +0000, Nick Hilliard via db-wg wrote:
Cynthia Revström via db-wg wrote on 07/01/2019 11:31:
I do like this idea with a checkbox, it gives flexibility while still achieving the goal. it will work until the point that your LIR is large enough that you need segmented / group access control for your DB objects. Then it will break. Which could be easily resolved with creating and naming SSO-LIR groups in LIR Portal and using them like that:
auth: SSO-LIR no.foobar.group1 or auth: SSO-LIR no.foobar group1
Piotr
If this is implemented then think the 2nd option "SSO-LIR no.foobar group1" is better. Kind regards, Cynthia Revström
* denis walker via db-wg
Just to clarify a point here. Are you suggesting that for all LIRs, all listed LIR (non-billing) administrators should be able to manage all the LIR's database objects that will all be maintained by this one 'magic' MNTNER object as "mnt-by:", "mnt-lower:", "mnt-routes"?
No, only that there should exist a method/functionality by which what you are describing above could be accomplised. Its use should not be made mandatory. That is, assuming this functionality is implemented as Cynthia envisioned, i.e., «auth: SSO-LIR cc.regid», then would be entirely optional to add that attribute to the maintainer object(s) used by the LIR. IFF it is added, however, then all the (non-billing) accounts associated with the «cc.regid» LIR should be authorised to maintain any objects where the maintainer object in question is included in the appropriate «mnt{,-by,-lower,-routes}:» attribute. This would be analogous to adding «auth: SSO bob@regid.cc» and «auth: SSO alice@regid.cc» to the maintainer object(s), assuming those RIPE NCC Access accounts are the only two on «cc.regid»'s user list. Another way it could be implemented is that all LIRs will automatically get such a «magic» NCC-managed maintainer object/handle which authorises all the the LIR's user accounts. The LIR could then use this magic maintainer handle in addition to, or in lieu of, regular self-managed maintainer objects/handles in the «mnt{,-by,-lower,-routes}:» attributes of its database objects. Or the LIR could opt to not use this magic maintainer object/handle for anything at all, of course. Does that clarify? Tore
Chairs, According to the process document linked to by Piotr, you are supposed to respond to NWI requests with either «yes» or «no». More than a month has elapsed since I requested the NWI and the last message was posted to this thread. When should I expect your answer? Tore * Tore Anderson via db-wg
* Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI.
Thanks for the pointer!
Chairs (cc-ed), could we have an NWI for this?
Rough problem statement for the kickstart phase follows:
There is currently no way to automatically sync the «auth: SSO x@y» attributes for a maintainer object with the list of (non-billing) users associated with an LIR.
This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places).
Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question.
It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well.
Tore
Hi Tore Sorry for the delay. This was on my ToDo list but just hadn´t got to that point yet. The DB-WG chairs agree this is suitable to be added to the list of Numbered Work Items as ¨NWI-8 LIR´s SSO Authentication Groups¨ I think the discussion we had in January, ending with Nick´s summary, could form the basis of the Problem Definition and the start of the Solution Definition. Lets focus on the Problem Definition first. I have included a draft Solution Definition below just to remind people where the discussion in January lead to. Do we agree on the Problem definition shown below?Just to get the terminology correct, in the portal UI are people referred to as ´users´ or ´contacts´? cheersdenisco-chair DB-WG Problem Definition LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. (Draft) Solution Definition -Technical Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups.-Each User can be a member of any number of named groups. (should there be a limit on number of groups?)-The authentication groups can be configured using the portal UI.-These groups can be referenced in MNTNER objects by a new authentication method ´SSO-LIR´. From: Tore Anderson via db-wg <db-wg@ripe.net> To: Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> Cc: db-wg@ripe.net; Aleksi Suhonen <Aleksi.Suhonen@axu.tm>; db-wg-chairs@ripe.net Sent: Monday, 11 February 2019, 8:49 Subject: Re: [db-wg] Idea: magic mntner for all LIR contacts Chairs, According to the process document linked to by Piotr, you are supposed to respond to NWI requests with either «yes» or «no». More than a month has elapsed since I requested the NWI and the last message was posted to this thread. When should I expect your answer? Tore * Tore Anderson via db-wg
* Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI.
Thanks for the pointer!
Chairs (cc-ed), could we have an NWI for this?
Rough problem statement for the kickstart phase follows:
There is currently no way to automatically sync the «auth: SSO x@y» attributes for a maintainer object with the list of (non-billing) users associated with an LIR.
This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places).
Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question.
It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well.
Tore
On 2019-02-12 03:29, denis walker via db-wg wrote:
Problem Definition
LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database.
(Draft) Solution Definition
-Technical Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups. -Each User can be a member of any number of named groups. (should there be a limit on number of groups?) -The authentication groups can be configured using the portal UI. -These groups can be referenced in MNTNER objects by a new authentication method ´SSO-LIR´.
To me this looks like what was suggested, if technical users are currently referring to admin and regular, but not billing. Regarding the limit on the number of groups, I personally don't have any real opinion on it, I can see good and bad things about having a limit on that. Kind regards, Cynthia Revström
Hi Denis, and thanks! I agree in principle, wbut would like to add the following bullet point to the Solution Definition: - There should be an automatic/implicit authentication group that contains all LIR user accounts with admin/regular entitlement level. This is, after all, my primary motivation for making the request. The ability to create custom groups containing subsets of this «all» group is not important to me. I'd also suggest to let the NCC know that the implementation could be staged if that is more convenient to them (i.e., implement database integration for the «all» group first, do the LIR Portal UI stuff for creating custom groups in a version 2.0). I'd also like to avoid being too prescriptive about the exact nomenclature and implementation details (e.g., an authentication method called «SSO-LIR») as I'd prefer to give the NCC's engineers freedom to come up with what they consider the best solution. [For example, imagine these groups could be referenced directly in mnt-by/ref/etc. attributes instead. Then many (most?) LIRs would no longer need to create any mntner objects at all, they could simply reference their implicit «all» group directly. This would seem like a more user- friendly and simple solution than require all LIRs to create a «glue» mntner object. I don't know if this is doable or even desirable from the NCC's point of view, but I would like them to have the freedom to consider such solutions too.] FWIW, the LIR Portal page is titled «User Accounts». An user account can have one of three pre-defined entitlement levels: Admin - «The Administrator will have full access to RIPE NCC services plus the right to manage other LIR contacts» Regular - «The Operator will have full access to RIPE NCC services» Billing - «The Billing user will have access to RIPE NCC billing information only» Tore * denis walker via db-wg
Hi Tore
Sorry for the delay. This was on my ToDo list but just hadn´t got to that point yet.
The DB-WG chairs agree this is suitable to be added to the list of Numbered Work Items as ¨NWI-8 LIR´s SSO Authentication Groups¨
I think the discussion we had in January, ending with Nick´s summary, could form the basis of the Problem Definition and the start of the Solution Definition.
Lets focus on the Problem Definition first. I have included a draft Solution Definition below just to remind people where the discussion in January lead to.
Do we agree on the Problem definition shown below? Just to get the terminology correct, in the portal UI are people referred to as ´users´ or ´contacts´?
cheers denis co-chair DB-WG
Problem Definition
LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database.
(Draft) Solution Definition
-Technical Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups. -Each User can be a member of any number of named groups. (should there be a limit on number of groups?) -The authentication groups can be configured using the portal UI. -These groups can be referenced in MNTNER objects by a new authentication method ´SSO-LIR´.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Tore Anderson via db-wg <db-wg@ripe.net> *To:* Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> *Cc:* db-wg@ripe.net; Aleksi Suhonen <Aleksi.Suhonen@axu.tm>; db-wg-chairs@ripe.net *Sent:* Monday, 11 February 2019, 8:49 *Subject:* Re: [db-wg] Idea: magic mntner for all LIR contacts
Chairs,
According to the process document linked to by Piotr, you are supposed to respond to NWI requests with either «yes» or «no».
More than a month has elapsed since I requested the NWI and the last message was posted to this thread. When should I expect your answer?
Tore
* Tore Anderson via db-wg
* Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI.
Thanks for the pointer!
Chairs (cc-ed), could we have an NWI for this?
Rough problem statement for the kickstart phase follows:
There is currently no way to automatically sync the «auth: SSO x@y <mailto:x@y>» attributes for a maintainer object with the list of (non-billing) users associated with an LIR.
This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places).
Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question.
It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well.
Tore
Personally I prefer an authentication scheme over a magic maintainer as you might want to be able to have a PGP auth or MD5 auth too as backup or for some IPAM software. I do however realize that this might be a bit harder as last time I looked at the SSO parts of the WHOIS server source code, there was no real integration with the real website in it other than the crowd cookie check. So while you could implement the magic maintainer with something external like a "task" that runs every night, a new auth scheme would require integration between the main website and the WHOIS source code. Also something like a magic maintainer could be implemented quite quickly I assume, where as a new auth scheme would take a lot longer (I am assuming). But all things considered, I do still prefer a new auth scheme for the reasons I mentioned above. Kind regards, Cynthia Revström On 2019-02-12 13:59, Tore Anderson via db-wg wrote:
Hi Denis, and thanks!
I agree in principle, wbut would like to add the following bullet point to the Solution Definition:
- There should be an automatic/implicit authentication group that contains all LIR user accounts with admin/regular entitlement level.
This is, after all, my primary motivation for making the request. The ability to create custom groups containing subsets of this «all» group is not important to me.
I'd also suggest to let the NCC know that the implementation could be staged if that is more convenient to them (i.e., implement database integration for the «all» group first, do the LIR Portal UI stuff for creating custom groups in a version 2.0).
I'd also like to avoid being too prescriptive about the exact nomenclature and implementation details (e.g., an authentication method called «SSO-LIR») as I'd prefer to give the NCC's engineers freedom to come up with what they consider the best solution.
[For example, imagine these groups could be referenced directly in mnt-by/ref/etc. attributes instead. Then many (most?) LIRs would no longer need to create any mntner objects at all, they could simply reference their implicit «all» group directly. This would seem like a more user- friendly and simple solution than require all LIRs to create a «glue» mntner object. I don't know if this is doable or even desirable from the NCC's point of view, but I would like them to have the freedom to consider such solutions too.]
FWIW, the LIR Portal page is titled «User Accounts». An user account can have one of three pre-defined entitlement levels:
Admin - «The Administrator will have full access to RIPE NCC services plus the right to manage other LIR contacts» Regular - «The Operator will have full access to RIPE NCC services» Billing - «The Billing user will have access to RIPE NCC billing information only»
Tore
* denis walker via db-wg
Hi Tore
Sorry for the delay. This was on my ToDo list but just hadn´t got to that point yet.
The DB-WG chairs agree this is suitable to be added to the list of Numbered Work Items as ¨NWI-8 LIR´s SSO Authentication Groups¨
I think the discussion we had in January, ending with Nick´s summary, could form the basis of the Problem Definition and the start of the Solution Definition.
Lets focus on the Problem Definition first. I have included a draft Solution Definition below just to remind people where the discussion in January lead to.
Do we agree on the Problem definition shown below? Just to get the terminology correct, in the portal UI are people referred to as ´users´ or ´contacts´?
cheers denis co-chair DB-WG
Problem Definition
LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database.
(Draft) Solution Definition
-Technical Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups. -Each User can be a member of any number of named groups. (should there be a limit on number of groups?) -The authentication groups can be configured using the portal UI. -These groups can be referenced in MNTNER objects by a new authentication method ´SSO-LIR´.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Tore Anderson via db-wg <db-wg@ripe.net> *To:* Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> *Cc:* db-wg@ripe.net; Aleksi Suhonen <Aleksi.Suhonen@axu.tm>; db-wg-chairs@ripe.net *Sent:* Monday, 11 February 2019, 8:49 *Subject:* Re: [db-wg] Idea: magic mntner for all LIR contacts
Chairs,
According to the process document linked to by Piotr, you are supposed to respond to NWI requests with either «yes» or «no».
More than a month has elapsed since I requested the NWI and the last message was posted to this thread. When should I expect your answer?
Tore
* Tore Anderson via db-wg
* Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI. Thanks for the pointer!
Chairs (cc-ed), could we have an NWI for this?
Rough problem statement for the kickstart phase follows:
There is currently no way to automatically sync the «auth: SSO x@y <mailto:x@y>» attributes for a maintainer object with the list of (non-billing) users associated with an LIR.
This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places).
Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question.
It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well.
Tore
Hi All We had a long discussion on this in January. I don't see any objections to this NWI so I would like the NCC to add this to the web page list of NWIs with the Problem Definition shown below. Can you arrange that Ed? Then we can move onto more discussion about the Solution Definition. cheersdenisco-chair DB-WG From: Cynthia Revström via db-wg <db-wg@ripe.net> To: Tore Anderson <tore@fud.no> Cc: "db-wg@ripe.net" <db-wg@ripe.net> Sent: Tuesday, 12 February 2019, 14:10 Subject: Re: [db-wg] NWI-8 LIR´s SSO Authentication Groups Personally I prefer an authentication scheme over a magic maintainer as you might want to be able to have a PGP auth or MD5 auth too as backup or for some IPAM software. I do however realize that this might be a bit harder as last time I looked at the SSO parts of the WHOIS server source code, there was no real integration with the real website in it other than the crowd cookie check. So while you could implement the magic maintainer with something external like a "task" that runs every night, a new auth scheme would require integration between the main website and the WHOIS source code. Also something like a magic maintainer could be implemented quite quickly I assume, where as a new auth scheme would take a lot longer (I am assuming). But all things considered, I do still prefer a new auth scheme for the reasons I mentioned above. Kind regards, Cynthia Revström On 2019-02-12 13:59, Tore Anderson via db-wg wrote:
Hi Denis, and thanks!
I agree in principle, wbut would like to add the following bullet point to the Solution Definition:
- There should be an automatic/implicit authentication group that contains all LIR user accounts with admin/regular entitlement level.
This is, after all, my primary motivation for making the request. The ability to create custom groups containing subsets of this «all» group is not important to me.
I'd also suggest to let the NCC know that the implementation could be staged if that is more convenient to them (i.e., implement database integration for the «all» group first, do the LIR Portal UI stuff for creating custom groups in a version 2.0).
I'd also like to avoid being too prescriptive about the exact nomenclature and implementation details (e.g., an authentication method called «SSO-LIR») as I'd prefer to give the NCC's engineers freedom to come up with what they consider the best solution.
[For example, imagine these groups could be referenced directly in mnt-by/ref/etc. attributes instead. Then many (most?) LIRs would no longer need to create any mntner objects at all, they could simply reference their implicit «all» group directly. This would seem like a more user- friendly and simple solution than require all LIRs to create a «glue» mntner object. I don't know if this is doable or even desirable from the NCC's point of view, but I would like them to have the freedom to consider such solutions too.]
FWIW, the LIR Portal page is titled «User Accounts». An user account can have one of three pre-defined entitlement levels:
Admin - «The Administrator will have full access to RIPE NCC services plus the right to manage other LIR contacts» Regular - «The Operator will have full access to RIPE NCC services» Billing - «The Billing user will have access to RIPE NCC billing information only»
Tore
* denis walker via db-wg
Hi Tore
Sorry for the delay. This was on my ToDo list but just hadn´t got to that point yet.
The DB-WG chairs agree this is suitable to be added to the list of Numbered Work Items as ¨NWI-8 LIR´s SSO Authentication Groups¨
I think the discussion we had in January, ending with Nick´s summary, could form the basis of the Problem Definition and the start of the Solution Definition.
Lets focus on the Problem Definition first. I have included a draft Solution Definition below just to remind people where the discussion in January lead to.
Do we agree on the Problem definition shown below? Just to get the terminology correct, in the portal UI are people referred to as ´users´ or ´contacts´?
cheers denis co-chair DB-WG
Problem Definition
LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database.
(Draft) Solution Definition
-Technical Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups. -Each User can be a member of any number of named groups. (should there be a limit on number of groups?) -The authentication groups can be configured using the portal UI. -These groups can be referenced in MNTNER objects by a new authentication method ´SSO-LIR´.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Tore Anderson via db-wg <db-wg@ripe.net> *To:* Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> *Cc:* db-wg@ripe.net; Aleksi Suhonen <Aleksi.Suhonen@axu.tm>; db-wg-chairs@ripe.net *Sent:* Monday, 11 February 2019, 8:49 *Subject:* Re: [db-wg] Idea: magic mntner for all LIR contacts
Chairs,
According to the process document linked to by Piotr, you are supposed to respond to NWI requests with either «yes» or «no».
More than a month has elapsed since I requested the NWI and the last message was posted to this thread. When should I expect your answer?
Tore
* Tore Anderson via db-wg
* Piotr Strzyzewski via db-wg
Look at this page https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items and start new NWI. Thanks for the pointer!
Chairs (cc-ed), could we have an NWI for this?
Rough problem statement for the kickstart phase follows:
There is currently no way to automatically sync the «auth: SSO x@y <mailto:x@y>» attributes for a maintainer object with the list of (non-billing) users associated with an LIR.
This leads to duplication of work (adding/removing newly hired/departed LIR administrators in two places).
Additionally, this increases the risk of unauthorised access, e.g., if an administrator has left an LIR but was only removed from the LIR portal, he might inappropriately retain access to manage database objects for the LIR in question.
It is therefore desirable to have a method to protect RIPE database objects so that they can be maintained by the list of (non-billing) user accounts currently associated with a specific LIR at any given time. That is, when a RIPE NCC Access account is removed from the LIR's user list, the database maintainer access should be automatically revoked for that account as well.
Tore
* denis walker via db-wg
We had a long discussion on this in January. I don't see any objections to this NWI so I would like the NCC to add this to the web page list of NWIs with the Problem Definition shown below. Can you arrange that Ed?
I can see it's up on the page now.
Then we can move onto more discussion about the Solution Definition.
In order to avoid design by committee it would be nice to hear an implementation proposal from the NCC at this point, I think. Is this something that can be arranged? Tore
Hi Tore, the DB team will get started on an implementation proposal for the DB-WG. Regards Ed
On 18 Feb 2019, at 10:05, Tore Anderson via db-wg <db-wg@ripe.net> wrote:
* denis walker via db-wg
We had a long discussion on this in January. I don't see any objections to this NWI so I would like the NCC to add this to the web page list of NWIs with the Problem Definition shown below. Can you arrange that Ed?
I can see it's up on the page now.
Then we can move onto more discussion about the Solution Definition.
In order to avoid design by committee it would be nice to hear an implementation proposal from the NCC at this point, I think. Is this something that can be arranged?
Tore
Thanks Ed. But keep in mind that there is no consensus yet on the final solution definition the community wants. The discussion has ranged from a 'magic' MNTNER object, to groups of SSO authorisations managed through the portal UI to Tore's latest suggestion of directly referencing these groups in the "mnt-xxx:" attributes. Tore I do like your idea:"[For example, imagine these groups could be referenced directly in mnt-by/ref/etc. attributes instead. Then many (most?) LIRs would no longer need to create any mntner objects at all, they could simply reference their implicit «all» group directly. This would seem like a more user- friendly and simple solution than require all LIRs to create a «glue» mntner object. I don't know if this is doable or even desirable from the NCC's point of view, but I would like them to have the freedom to consider such solutions too.]" Almost anything is 'doable', but it is the communities point of view that is most important here. The desired solution comes from the community then the NCC looks at the impact and possible implementation of that solution and may suggest technical changes. Using these groups directly in "mnt-xxx:" attributes does take us a step further in the direction of personalised auth. An issue that has been discussed several times in this working group. It also keeps more of your security details private. It eliminates the need for the MNTNER object, which is just a box holding credentials that the public has no need to see. As a later extra step we could even include management of passwords and PGP through the portal UI which could be added to the groups. Then anyone with a portal account no longer needs to create any MNTNER objects. (I'm not suggesting that at this stage as that is feature creep which pushes the whole idea further down the road.) An extra benefit of this idea is that it is totally optional and backwards compatible. So anyone who doesn't want to change anything has no need to do anything. On a technical note I would also add that we cannot build in a dependency for the RIPE Database updates on the portal service being available. The RIPE Database update service has a higher resilience than the portal and must not be compromised. Therefore the credential groups managed through the portal UI need to be available to the RIPE Database in an offline capacity or maybe even stored in some way as private data within the database itself. That is something for the NCC to think about. Comments and thoughts from anyone are always welcome... cheersdenisco-chair DB-WG On Monday, 18 February 2019, 16:54:06 CET, Edward Shryane <eshryane@ripe.net> wrote: Hi Tore, the DB team will get started on an implementation proposal for the DB-WG. Regards Ed
On 18 Feb 2019, at 10:05, Tore Anderson via db-wg <db-wg@ripe.net> wrote:
* denis walker via db-wg
We had a long discussion on this in January. I don't see any objections to this NWI so I would like the NCC to add this to the web page list of NWIs with the Problem Definition shown below. Can you arrange that Ed?
I can see it's up on the page now.
Then we can move onto more discussion about the Solution Definition.
In order to avoid design by committee it would be nice to hear an implementation proposal from the NCC at this point, I think. Is this something that can be arranged?
Tore
participants (9)
-
Cynthia Revström -
denis walker -
Edward Shryane -
Gert Doering -
Nick Hilliard -
Piotr Strzyzewski -
ripedenis＠yahoo.co.uk
-
Sander Steffann -
Tore Anderson