This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Idea: magic mntner for all LIR contacts
- Previous message (by thread): [db-wg] Idea: magic mntner for all LIR contacts
- Next message (by thread): [db-wg] Idea: magic mntner for all LIR contacts
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at foobar.org
Mon Jan 7 11:48:09 CET 2019
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 members: 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
- Previous message (by thread): [db-wg] Idea: magic mntner for all LIR contacts
- Next message (by thread): [db-wg] Idea: magic mntner for all LIR contacts
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]