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
