Hi All
We had a long discussion on this in January. I don't see any objections to this
NWI so I would like the NCC to add this to the web page list of NWIs with the
Problem Definition shown below. Can you arrange that Ed?
Then we can move onto more discussion about the Solution Definition.
cheersdenisco-chair DB-WG
From: Cynthia Revström via db-wg <db-wg@ripe.net>
To: Tore Anderson <t...@fud.no>
Cc: "db-wg@ripe.net" <db-wg@ripe.net>
Sent: Tuesday, 12 February 2019, 14:10
Subject: Re: [db-wg] NWI-8 LIR´s SSO Authentication Groups
Personally I prefer an authentication scheme over a magic maintainer as
you might want to be able to have a PGP auth or MD5 auth too as backup
or for some IPAM software.
I do however realize that this might be a bit harder as last time I
looked at the SSO parts of the WHOIS server source code, there was no
real integration with the real website in it other than the crowd cookie
check.
So while you could implement the magic maintainer with something
external like a "task" that runs every night, a new auth scheme would
require integration between the main website and the WHOIS source code.
Also something like a magic maintainer could be implemented quite
quickly I assume, where as a new auth scheme would take a lot longer (I
am assuming).
But all things considered, I do still prefer a new auth scheme for the
reasons I mentioned above.
Kind regards,
Cynthia Revström
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.strzyzew...@polsl.pl>
>> *Cc:* db-wg@ripe.net; Aleksi Suhonen <aleksi.suho...@axu.tm>;
>> db-wg-cha...@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
>>>
>>
>>
>>
