On 2019-02-12 13:59, Tore Anderson via db-wg wrote:
> Hi Denis, and thanks!
>
> I agree in principle, wbut would like to add the following bullet point to
> the Solution Definition:
>
> - There should be an automatic/implicit authentication group that contains
>    all LIR user accounts with admin/regular entitlement level.
>
> This is, after all, my primary motivation for making the request. The
> ability to create custom groups containing subsets of this «all» group is
> not important to me.
>
> I'd also suggest to let the NCC know that the implementation could be
> staged if that is more convenient to them (i.e., implement database
> integration for the «all» group first, do the LIR Portal UI stuff for
> creating custom groups in a version 2.0).
>
> I'd also like to avoid being too prescriptive about the exact nomenclature
> and implementation details (e.g., an authentication method called
> «SSO-LIR») as I'd prefer to give the NCC's engineers freedom to come up
> with what they consider the best solution.
>
> [For example, imagine these groups could be referenced directly in
> mnt-by/ref/etc. attributes instead. Then many (most?) LIRs would no longer
> need to create any mntner objects at all, they could simply reference
> their implicit «all» group directly. This would seem like a more user-
> friendly and simple solution than require all LIRs to create a «glue»
> mntner object. I don't know if this is doable or even desirable from the
> NCC's point of view, but I would like them to have the freedom to consider
> such solutions too.]
>
> FWIW, the LIR Portal page is titled «User Accounts». An user account can
> have one of three pre-defined entitlement levels:
>
> Admin - «The Administrator will have full access to RIPE NCC services plus
> the right to manage other LIR contacts»
> Regular - «The Operator will have full access to RIPE NCC services»
> Billing - «The Billing user will have access to RIPE NCC billing
> information only»
>
> Tore
>
> * denis walker via db-wg
>> Hi Tore
>>
>> Sorry for the delay. This was on my ToDo list but just hadn´t got to that point yet.
>>
>> The DB-WG chairs agree this is suitable to be added to the list of Numbered Work Items as ¨NWI-8 LIR´s SSO Authentication Groups¨
>>
>> I think the discussion we had in January, ending with Nick´s summary, could form the basis of the Problem Definition and the start of the Solution Definition.
>>
>> Lets focus on the Problem Definition first. I have included a draft Solution Definition below just to remind people where the discussion in January lead to.
>>
>> Do we agree on the Problem definition shown below?
>> Just to get the terminology correct, in the portal UI are people referred to as ´users´ or ´contacts´?
>>
>> cheers
>> denis
>> co-chair DB-WG
>>
>>
>> Problem Definition
>>
>> LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database.
>>
>>
>> (Draft) Solution Definition
>>
>> -Technical Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups.
>> -Each User can be a member of any number of named groups. (should there be a limit on number of groups?)
>> -The authentication groups can be configured using the portal UI.
>> -These groups can be referenced in MNTNER objects by a new authentication method ´SSO-LIR´.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> *From:* Tore Anderson via db-wg <db-wg@ripe.net>
>> *To:* Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl>
>> *Cc:* db-wg@ripe.net; Aleksi Suhonen <Aleksi.Suhonen@axu.tm>; db-wg-chairs@ripe.net
>> *Sent:* Monday, 11 February 2019, 8:49
>> *Subject:* Re: [db-wg] Idea: magic mntner for all LIR contacts
>>
>> Chairs,
>>
>> According to the process document linked to by Piotr, you are supposed to
>> respond to NWI requests with either «yes» or «no».
>>
>> More than a month has elapsed since I requested the NWI and the last
>> message was posted to this thread. When should I expect your answer?
>>
>> Tore
>>
>> * Tore Anderson via db-wg
>>
>>> * Piotr Strzyzewski via db-wg
>>>
>>>> Look at this page
>>>> https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items
>>>> and start new NWI.
>>> Thanks for the pointer!
>>>
>>> Chairs (cc-ed), could we have an NWI for this?
>>>
>>> Rough problem statement for the kickstart phase follows:
>>>
>>> There is currently no way to automatically sync the «auth: SSO x@y <mailto:x@y>»
>>> attributes for a maintainer object with the list of (non-billing) users
>>> associated with an LIR.
>>>
>>> This leads to duplication of work (adding/removing newly hired/departed
>>> LIR administrators in two places).
>>>
>>> Additionally, this increases the risk of unauthorised access, e.g., if an
>>> administrator has left an LIR but was only removed from the LIR portal,
>>> he might inappropriately retain access to manage database objects for the
>>> LIR in question.
>>>
>>> It is therefore desirable to have a method to protect RIPE database
>>> objects so that they can be maintained by the list of (non-billing)
>>> user accounts currently associated with a specific LIR at any given
>>> time. That is, when a RIPE NCC Access account is removed from the LIR's
>>> user list, the database maintainer access should be automatically
>>> revoked for that account as well.
>>>
>>> Tore
>>>
>>
>>
>>