[db-wg] NWI-8 LIR´s SSO Authentication Groups

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 at ripe.net>
> *To:* Piotr Strzyzewski <Piotr.Strzyzewski at polsl.pl>
> *Cc:* db-wg at ripe.net; Aleksi Suhonen <Aleksi.Suhonen at axu.tm>; db-wg-chairs at 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 at y <mailto:x at 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
>>
> 
> 
> 
>