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 <n...@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: f...@example.com
> members: b...@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
>
