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: 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)?
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
signature.asc
Description: PGP signature
