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