[db-wg] Idea: magic mntner for all LIR contacts

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 at ripe.net>
> *To:* Nick Hilliard <nick at foobar.org>
> *Cc:* db-wg at 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 at example.com <mailto:foo at example.com>
> > members: bar at example.org <mailto:bar at 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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20190107/ba4abff6/attachment.html>