Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #11580 > unrolled thread

Salsa as authentication provider for Debian

Back to article view | Back to linux.debian.project

Contents

  Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-06 18:00 +0200
    Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-06 18:20 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-06 20:50 +0200
        Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-06 21:20 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 10:40 +0200
            Re: Salsa as authentication provider for Debian Geert Stappers <stappers@debian.org> - 2020-04-07 11:30 +0200
            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:10 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 17:40 +0200
                Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 18:00 +0200
                  Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 09:50 +0200
                    Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-09 12:20 +0200
                      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 09:30 +0200
                  Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-10 14:50 +0200
                    Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-10 18:00 +0200
                      Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-10 18:30 +0200
                        Re: Salsa as authentication provider for Debian Russ Allbery <rra@debian.org> - 2020-04-10 19:30 +0200
                          Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-10 20:20 +0200
                            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-10 22:10 +0200
                              Re: Salsa as authentication provider for Debian Russ Allbery <rra@debian.org> - 2020-04-10 22:30 +0200
        Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-06 21:50 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 09:50 +0200
            Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 10:30 +0200
            Re: Salsa as authentication provider for Debian Felix Lechner <felix.lechner@lease-up.com> - 2020-04-10 21:50 +0200
              Re: Salsa as authentication provider for Debian kuLa <kula@kulisz.net> - 2020-04-11 08:30 +0200
              Re: Salsa as authentication provider for Debian Jonathan Carter <jcc@debian.org> - 2020-04-11 12:10 +0200
                Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-11 19:30 +0200
                  Re: Salsa as authentication provider for Debian Sam Hartman <leader@debian.org> - 2020-04-11 20:20 +0200
      Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-07 10:40 +0200
        Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:30 +0200
          Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-10 12:20 +0200
            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-10 19:10 +0200
    Re: Salsa as authentication provider for Debian Holger Levsen <holger@layer-acht.org> - 2020-04-06 21:00 +0200
    Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 12:40 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 14:10 +0200
        Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 14:40 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 15:30 +0200
            Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 15:40 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 16:10 +0200
                Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 16:30 +0200
                  Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:50 +0200
        Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-07 16:30 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 17:00 +0200
      Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:40 +0200
        Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-08 22:30 +0200
    Re: Salsa as authentication provider for Debian Paul Wise <pabs@debian.org> - 2020-04-07 17:30 +0200
      Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 17:40 +0200
        Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-07 19:00 +0200
          Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-10 21:50 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 19:00 +0200
      Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-07 20:30 +0200
        Re: Salsa as authentication provider for Debian Paul Wise <pabs@debian.org> - 2020-04-08 08:00 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 11:40 +0200
    Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-08 12:30 +0200
      Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 18:00 +0200
      Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-08 21:20 +0200
        Re: Salsa as authentication provider for Debian Steve McIntyre <93sam@debian.org> - 2020-04-08 21:40 +0200
        Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 09:30 +0200
          Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-09 20:10 +0200
            Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 20:30 +0200
            Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-09 23:30 +0200
              Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-12 10:40 +0200
                Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-12 18:50 +0200
                  Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-13 18:50 +0200
                    Re: Salsa as authentication provider for Debian Pirate Praveen <praveen@onenetbeyond.org> - 2020-04-13 19:50 +0200
    Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:00 +0200
      Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:20 +0200
        Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 15:00 +0200
      Re: Salsa as authentication provider for Debian Ulrike Uhlig <ulrike@debian.org> - 2020-04-08 14:20 +0200
        Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:30 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 15:30 +0200
            Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-08 16:10 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 16:30 +0200
            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 18:10 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 10:10 +0200
        Re: Salsa as authentication provider for Debian Ole Streicher <olebole@debian.org> - 2020-04-08 14:40 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 21:50 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 14:20 +0200
      Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-08 14:40 +0200
        Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:50 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 15:00 +0200
            Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-08 15:20 +0200
        Re: Salsa as authentication provider for Debian Julien Cristau <jcristau@debian.org> - 2020-04-10 21:50 +0200
          Re: Salsa as authentication provider for Debian Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-11 09:30 +0200
            Re: Salsa as authentication provider for Debian Julien Cristau <jcristau@debian.org> - 2020-04-11 19:30 +0200
              Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-11 20:10 +0200
              Re: Salsa as authentication provider for Debian Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 07:30 +0200
                Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-12 17:00 +0200
                  Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-13 16:00 +0200
                    Re: Salsa as authentication provider for Debian Peter Palfrader <weasel@debian.org> - 2020-04-13 21:00 +0200
                      Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-13 21:30 +0200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#11596

On Tue, 7 Apr 2020 13:50:06 +0200
Enrico Zini <enrico@enricozini.org> wrote:

> On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
> 
> I would like to avoid stalling progress on sso on things like analysis
> paralysis, or like sorting out deployment details, as happened in the
> last years.

I can very much appreciate a desire to get a replacement rolled out as quickly
as possible. The more I learn about the current situation [1], the more alarming
it is. However, please don't consider the work Lucas and I are doing as
stalling. I was unaware that the whole effort stalled. I'm currently between
contracts and have plenty of free time to make something happen.

I also like to think of a myself as a good masochist. You can expect me to
stick around for the long term. :)

[1] oh my...
    https://wiki.debian.org/DebianSingleSignOn#If_you_ARE_NOT_.28yet.29_a_Debian_Developer

> I'll ask you the same question I asked Luca: is there something in the
> Salsa proposal that would prevent further experimentation with LLNG and
> eventually possibly integrating it into the ecosystem, or migrating to
> it?

Aside from the security concern I raised earlier, it's largely a "gut feeling"
that comes from seeing how quickly legacy quirks develop in any new deployment.
If Salsa needs to make any assumption or enforcements that Alioth did not,
those will need to be accounted for in the new solution. Additionally, we
already have a clean path 

Something that comes to mind is what it would take to migrate accounts from
Salsa to somewhere else. Does gitlab provide user exports? As unfortunate as it
is that alioth's DB is now a flat-file managed by hand, it provides a very
simple and easy way to import all of that data.


> [...]
> As a side effect of an interim on Salsa, services can begin to migrate
> from client certificates to OIDC, switching to a mode widely used,
> usable, and flexible standard, which I wouldn't be surprised if it would
> make things easier when moving to something else later on.

If there aren't any practical issues with migrating away from salsa in the
future, then I wouldn't have any objection, but the voice in the back of my
head is screaming pretty loudly right now.

-- 
Michael Lustfield

[toc] | [prev] | [next] | [standalone]

#11597

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 07, 2020 at 09:14:11AM -0500, Michael Lustfield wrote:

> I can very much appreciate a desire to get a replacement rolled out as quickly
> as possible. The more I learn about the current situation [1], the more alarming
> it is. However, please don't consider the work Lucas and I are doing as
> stalling. I was unaware that the whole effort stalled. I'm currently between
> contracts and have plenty of free time to make something happen.
> 
> I also like to think of a myself as a good masochist. You can expect me to
> stick around for the long term. :)

That's great, and I also don't want the Salsa improvement we proposed to
be a blocker for further developments.

As far as I'm concerned, we could get started with migrating services to
OIDC consumers[1], unblocking new non-DD access to services, and
cleaning up the status quo a bit.

Sooner or later, your and Luca's work (or somebody else's, or all of
them) can get validated, and can pick it the situation from where we
left it and keep improving.


[1] or even simply libapache2-mod-auth-openidc, since the current cert
    system is handled by apache anyway


> Aside from the security concern I raised earlier, it's largely a "gut feeling"
> that comes from seeing how quickly legacy quirks develop in any new deployment.
> If Salsa needs to make any assumption or enforcements that Alioth did not,
> those will need to be accounted for in the new solution. Additionally, we
> already have a clean path 

I don't understand what you mean with "any assumption of enforcements".


> Something that comes to mind is what it would take to migrate accounts from
> Salsa to somewhere else. Does gitlab provide user exports? As unfortunate as it
> is that alioth's DB is now a flat-file managed by hand, it provides a very
> simple and easy way to import all of that data.

Gitlab does indeed provide user exports: some more details are in the
"Exit strategy" part of the proposal Waldi posted.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11623

reminder: I'm replying linearly and from what I know (keycloak, SAML and
OIDC).


On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
> Le 05/04/2020 à 20:46, Bastian Blank a écrit :
> I can help if you want to use lemondap-ng (LLNG:
> https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng)

Cool.

> This requires to change all services. Using a SSO is easier here:
> gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app
> without having to change to many things. LLNG handlers are directly
> included in Apache/Nginx configuration and provides HTTP-headers to the
> web app.

Or Apache modules like mod-auth-openidc (OIDC) or mod-auth-mellon
(SAML).

> Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and
> any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal
> then becomes transparent

Keycloak, as a broker, is similar. Service provider can be using one
protocol and the identity provider another.

> It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps
> more safe to manage users elsewhere (custom app) and make GitLab a slave
> of SSO system. LLNG provides a plugin engine for that.

Gitlab can use OIDC for OmniAuth, so it can authenticate against any
OIDC-compliant IdP, LLNG and Keycloak included.

> NB: KeyCloak is free but this needs to stay in last version, else you
> need a RedHat-SSO support. LLNG is totally free, written in Perl and JS;
> and Debian has a lot of Perl-Gurus ;-).

Redhat has the distinction (thankfully) of not following a 'freemium'
model (at least for Directory389 and Keycloak). The features available
in RedHat SSO and Keycloak are identical. Redhat SSO lags behind
Keycloak but may include fixes not yet ported to Keycloak. Keycloak is
also totally free and, yes, is written in Java.

> I can give some accounts to demo platform: https://auth.openid.club/
> [dev platform, so sometime broken...] or install an instance in a Debian
> machine if you want to try it.


Please work with Michael Lustfield (IRC MTecknology) as he is also
interested in setting upa Debian-specific instance of LLNG.

> Resume of proposition:
>  * all users managed by SSO;

Agree!

>  * self-registration authorized with "-guest"
>    in a distinct LDAP branch

More thought required but don't disagree.

>  * GitLab becomes a slave of SSO using SAML (or OIDC)

Agree!

>  * other applications are protected by handlers/GateKeepers. If LLNG is
>    chosen, just to add few lines in Nginx configuration

Agree and/or mod-auth-openidc/mod-auth-lemon, etc.

>  * new applications can be protected using handlers, SAML, CAS, OIDC,...

Agree but with order of preference being OIDC, SAML and... way over
there, almost too distant to see... CAS.

> <as usual, sorry for my poor English>

Very helpful response!

-- 
Luca Filipozzi

[toc] | [prev] | [next] | [standalone]

#11630

Le 08/04/2020 à 17:28, Luca Filipozzi a écrit :
> reminder: I'm replying linearly and from what I know (keycloak, SAML and
> OIDC).
> 
> 
> On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
>> Le 05/04/2020 à 20:46, Bastian Blank a écrit :
>> I can help if you want to use lemondap-ng (LLNG:
>> https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng)
> 
> Cool.
> 
>> This requires to change all services. Using a SSO is easier here:
>> gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app
>> without having to change to many things. LLNG handlers are directly
>> included in Apache/Nginx configuration and provides HTTP-headers to the
>> web app.
> 
> Or Apache modules like mod-auth-openidc (OIDC) or mod-auth-mellon
> (SAML).

Hi,

LLNG handlers are apache modules. The difference is that they don't only
manage authentication but also authorizations

>> Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and
>> any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal
>> then becomes transparent
> 
> Keycloak, as a broker, is similar. Service provider can be using one
> protocol and the identity provider another.
> 
>> It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps
>> more safe to manage users elsewhere (custom app) and make GitLab a slave
>> of SSO system. LLNG provides a plugin engine for that.
> 
> Gitlab can use OIDC for OmniAuth, so it can authenticate against any
> OIDC-compliant IdP, LLNG and Keycloak included.
> 
>> NB: KeyCloak is free but this needs to stay in last version, else you
>> need a RedHat-SSO support. LLNG is totally free, written in Perl and JS;
>> and Debian has a lot of Perl-Gurus ;-).
> 
> Redhat has the distinction (thankfully) of not following a 'freemium'
> model (at least for Directory389 and Keycloak). The features available
> in RedHat SSO and Keycloak are identical. Redhat SSO lags behind
> Keycloak but may include fixes not yet ported to Keycloak. Keycloak is
> also totally free and, yes, is written in Java.
> 
>> I can give some accounts to demo platform: https://auth.openid.club/
>> [dev platform, so sometime broken...] or install an instance in a Debian
>> machine if you want to try it.
> 
> 
> Please work with Michael Lustfield (IRC MTecknology) as he is also
> interested in setting upa Debian-specific instance of LLNG.

With pleasure !

>> Resume of proposition:
>>  * all users managed by SSO;
> 
> Agree!
> 
>>  * self-registration authorized with "-guest"
>>    in a distinct LDAP branch
> 
> More thought required but don't disagree.
> 
>>  * GitLab becomes a slave of SSO using SAML (or OIDC)
> 
> Agree!
> 
>>  * other applications are protected by handlers/GateKeepers. If LLNG is
>>    chosen, just to add few lines in Nginx configuration
> 
> Agree and/or mod-auth-openidc/mod-auth-lemon, etc.
> 
>>  * new applications can be protected using handlers, SAML, CAS, OIDC,...
> 
> Agree but with order of preference being OIDC, SAML and... way over
> there, almost too distant to see... CAS.

Of course, old protocol.

Choosing between handlers and federation protocols depends on how we
want to manage authorizations:
 * centralized authorization: handlers (authorization managed by manager
   application, websites are filtered globally or using regxp on URLs
 * managed in application: both way

This is the choice to do (both ways are possible simultaneously)

>> <as usual, sorry for my poor English>
> 
> Very helpful response!

Thanks ;-)

---
/me has worked for 15 years on Identity and Access Management (IAM) topics

[toc] | [prev] | [next] | [standalone]

#11598

On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:

> ## Highlevel plan

I'd like to learn a bit about what the effects for Debian account
holders and service admins will be.

> - Salsa becomes primary source of user info and authentication for secondary
>   services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing
>   sso.debian.org.

It sounds like the answer is no, but does Salsa, Keycloak or
LemonLDAP::NG support TLS client certs?

So it sounds like Debian would be switching our SSO authentication
protocol from TLS client certs directly supported by TLS clients to
something based on HTTP redirects, referrers and cookies and that
requires a browser in order to login?

It seems like one side effect of the protocol change is that login
events are centralised on the SSO service rather than at each
individual service.

Is there anything else that account holders need to be aware of?

> - nm.debian.org uses Salsa usernames by default to populate LDAP usernames when
>   creating accounts, and stores OIDC subject to strongly correlate between
>   Salsa and Debian LDAP users.

Is it intended that service maintainers each implement OpenID Connect
etc within their service code using existing libraries, or should we
use something like the mod_auth_openidc Apache module to pass
authentication details to service code.

https://github.com/zmartzone/mod_auth_openidc

Can services using non-HTTP protocols be authenticated with OpenID Connect etc?

Is it intended that there be moderation at account creation time? In
our experience with the Debian wiki, a large amount of spammers
attempt to sign up. I hear that Salsa gets a lot of spammers signing
up too and those are manually cleaned up if they do something spammy.
For the wiki we found the best way to prevent spammers from signing up
is human moderation. Even that doesn't always help as I've let
spammers sign up before based on the content of their signup emails,
but it is a good start. One very nice aspect of the wiki signup
moderation is that the team can respond to aspects of the signup
email, welcoming the applicant with pointers to documentation,
suggestions of ideas on how to help, mailing lists to join and so on.

Is there anything else that service admins need to be aware of?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#11599

Le 07/04/2020 à 17:20, Paul Wise a écrit :
> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:
> 
>> ## Highlevel plan
> 
> I'd like to learn a bit about what the effects for Debian account
> holders and service admins will be.
> 
>> - Salsa becomes primary source of user info and authentication for secondary
>>   services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing
>>   sso.debian.org.
> 
> It sounds like the answer is no, but does Salsa, Keycloak or
> LemonLDAP::NG support TLS client certs?

LLNG and KeyCloack support TLS authentication, 2FA,... See
https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases
for a complete list of LLNG supported authentication mechanisms

> So it sounds like Debian would be switching our SSO authentication
> protocol from TLS client certs directly supported by TLS clients to
> something based on HTTP redirects, referrers and cookies and that
> requires a browser in order to login?

Authentication gives an "authenticationLevel". You can restrict some
applications to TLS, some other to "password+2FA or TLS" and authorize
some other to use simple authentication

> It seems like one side effect of the protocol change is that login
> events are centralised on the SSO service rather than at each
> individual service.
> 
> Is there anything else that account holders need to be aware of?
> 
>> - nm.debian.org uses Salsa usernames by default to populate LDAP usernames when
>>   creating accounts, and stores OIDC subject to strongly correlate between
>>   Salsa and Debian LDAP users.

Application profiles can be managed by SSO (give profile to app and/or
restrict some URL to a particular group [handler/GateKeeper only])

> Is it intended that service maintainers each implement OpenID Connect
> etc within their service code using existing libraries, or should we
> use something like the mod_auth_openidc Apache module to pass
> authentication details to service code.

Both are possible but handler/GateKeeper can do the job

> https://github.com/zmartzone/mod_auth_openidc
> 
> Can services using non-HTTP protocols be authenticated with OpenID Connect etc?
> 
> Is it intended that there be moderation at account creation time? In
> our experience with the Debian wiki, a large amount of spammers
> attempt to sign up. I hear that Salsa gets a lot of spammers signing
> up too and those are manually cleaned up if they do something spammy.

Yes, possible

> For the wiki we found the best way to prevent spammers from signing up
> is human moderation. Even that doesn't always help as I've let
> spammers sign up before based on the content of their signup emails,
> but it is a good start. One very nice aspect of the wiki signup
> moderation is that the team can respond to aspects of the signup
> email, welcoming the applicant with pointers to documentation,
> suggestions of ideas on how to help, mailing lists to join and so on.
> 
> Is there anything else that service admins need to be aware of?

[toc] | [prev] | [next] | [standalone]

#11601

>>>>> "Xavier" == Xavier  <yadd@debian.org> writes:

    Xavier> Le 07/04/2020 à 17:20, Paul Wise a écrit :
    >> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:
    >> 
    >>> ## Highlevel plan
    >> 
    >> I'd like to learn a bit about what the effects for Debian account
    >> holders and service admins will be.
    >> 
    >>> - Salsa becomes primary source of user info and authentication
    >>> for secondary services via OpenID Connect (OAuth2), for both DDs
    >>> and non-DDs, replacing sso.debian.org.
    >> 
    >> It sounds like the answer is no, but does Salsa, Keycloak or
    >> LemonLDAP::NG support TLS client certs?

    Xavier> LLNG and KeyCloack support TLS authentication, 2FA,... See
    Xavier> https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases
    Xavier> for a complete list of LLNG supported authentication
    Xavier> mechanisms

I authenticate using TLS to the SSO server.
But then I use http redirects or JSON tokens to authenticate to the
protected app, right?

llng does not end up being a short-lived CA like the current
sso.debian.org

[toc] | [prev] | [next] | [standalone]

#11656

Le 07/04/2020 à 18:50, Sam Hartman a écrit :
>>>>>> "Xavier" == Xavier  <yadd@debian.org> writes:
> 
>     Xavier> Le 07/04/2020 à 17:20, Paul Wise a écrit :
>     >> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:
>     >> 
>     >>> ## Highlevel plan
>     >> 
>     >> I'd like to learn a bit about what the effects for Debian account
>     >> holders and service admins will be.
>     >> 
>     >>> - Salsa becomes primary source of user info and authentication
>     >>> for secondary services via OpenID Connect (OAuth2), for both DDs
>     >>> and non-DDs, replacing sso.debian.org.
>     >> 
>     >> It sounds like the answer is no, but does Salsa, Keycloak or
>     >> LemonLDAP::NG support TLS client certs?
> 
>     Xavier> LLNG and KeyCloack support TLS authentication, 2FA,... See
>     Xavier> https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases
>     Xavier> for a complete list of LLNG supported authentication
>     Xavier> mechanisms
> 
> I authenticate using TLS to the SSO server.
> But then I use http redirects or JSON tokens to authenticate to the
> protected app, right?

Hi,

Yes or secured-cookie. OIDC or SAML share authentication level with
applications. With LLNG ≥ 2.0, you can restrict OIDC/SAML using a rule
(which can read auth level). Handlers applies the rule given by LLNG so
they can require a strong level or not

> llng does not end up being a short-lived CA like the current
> sso.debian.org

SSL handshake is done by portal web server, so you have the same
features than with any webserver

[toc] | [prev] | [next] | [standalone]

#11600

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 07, 2020 at 03:20:52PM +0000, Paul Wise wrote:

> I'd like to learn a bit about what the effects for Debian account
> holders and service admins will be.

Thanks, I'll answer where I can.

I understand that you're exploring all possible corner cases that might
change and we might have to document or generally be aware of, and are
not implying that any change in the areas you explore should be
considered blockers for migrations away from the status quo.


> > - Salsa becomes primary source of user info and authentication for secondary
> >   services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing
> >   sso.debian.org.
> 
> It sounds like the answer is no, but does Salsa, Keycloak or
> LemonLDAP::NG support TLS client certs?

At least as a transition period, I intend to add OIDC authentication to
sso.debian.org via libapache2-mod-auth-openidc or something equivalent,
so that services that haven't migrated to OIDC can keep working.

I guess the same can be done authenticating against Keycloak, LLNG, or
most other things we might end up using, although I hope that if
sso.debian.org ends up not being needed, we can turn it off after
transitions have transitioned: I'm a big fan of reducing the amount of
custom code that I have to maintain.


> So it sounds like Debian would be switching our SSO authentication
> protocol from TLS client certs directly supported by TLS clients to
> something based on HTTP redirects, referrers and cookies and that
> requires a browser in order to login?

Technically yes. Practically, things like OIDC are standard setups, and
there are standard ways to deal with non-browser access, like API keys.

nm.debian.org for example already supports API keys without the need of
a client certificate.


> Is it intended that service maintainers each implement OpenID Connect
> etc within their service code using existing libraries, or should we
> use something like the mod_auth_openidc Apache module to pass
> authentication details to service code.
> 
> https://github.com/zmartzone/mod_auth_openidc

I suppose each service can choose as they see fit. The apache module
would provide a handy migration strategy from the current sso, keeping
things handled at the web server level.

Each service can decide what to do according to what options are
provided by their underlying frameworks: OIDC is a widely supported and
adopted standard, and it could be that using the corresponding
functionality of Django or whatever framework one has, turns out to be
easier for development and maintenance than the web server module.

Both options would be available, anyway.

If we really find out that we need a CA issuing client certs for some
kinds of services, we can still keep maintaining sso.debian.org: it's a
simple enough codebase and I think most people would be able to pick it
up and maintain it as a CA service for our SSO federation.

Note that I'm not aware of anything using sso.debian.org certificates
outside a browser. I wrote and published example code to do that years
ago, and haven't seen any adoption or even feedback.


> Can services using non-HTTP protocols be authenticated with OpenID Connect etc?
> 
> Is it intended that there be moderation at account creation time? In
> our experience with the Debian wiki, a large amount of spammers
> attempt to sign up. I hear that Salsa gets a lot of spammers signing
> up too and those are manually cleaned up if they do something spammy.
> For the wiki we found the best way to prevent spammers from signing up
> is human moderation. Even that doesn't always help as I've let
> spammers sign up before based on the content of their signup emails,
> but it is a good start. One very nice aspect of the wiki signup
> moderation is that the team can respond to aspects of the signup
> email, welcoming the applicant with pointers to documentation,
> suggestions of ideas on how to help, mailing lists to join and so on.

I defer to Salsa people for this part.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11602

Hi Paul

On Tue, Apr 07, 2020 at 03:20:52PM +0000, Paul Wise wrote:
> It sounds like the answer is no, but does Salsa, Keycloak or
> LemonLDAP::NG support TLS client certs?

No, Salsa does not support TLS client certs.

> So it sounds like Debian would be switching our SSO authentication
> protocol from TLS client certs directly supported by TLS clients to
> something based on HTTP redirects, referrers and cookies and that
> requires a browser in order to login?

Using a browser is the primary method for login with OIDC, yes.

> It seems like one side effect of the protocol change is that login
> events are centralised on the SSO service rather than at each
> individual service.

No, not really.  The services ask the SSO service for the identity of
the user and get an attestation back.  So each service needs to handle
it's own login.

> Is there anything else that account holders need to be aware of?

No.

> > - nm.debian.org uses Salsa usernames by default to populate LDAP usernames when
> >   creating accounts, and stores OIDC subject to strongly correlate between
> >   Salsa and Debian LDAP users.
> Is it intended that service maintainers each implement OpenID Connect
> etc within their service code using existing libraries, or should we
> use something like the mod_auth_openidc Apache module to pass
> authentication details to service code.
> https://github.com/zmartzone/mod_auth_openidc

This is up to the service maintainers.  I for example use
https://github.com/oauth2-proxy/oauth2-proxy

> Can services using non-HTTP protocols be authenticated with OpenID Connect etc?

In theory yes.  Dovecot for example supports this.

> Is it intended that there be moderation at account creation time? In
> our experience with the Debian wiki, a large amount of spammers
> attempt to sign up. I hear that Salsa gets a lot of spammers signing
> up too and those are manually cleaned up if they do something spammy.

Currently moderation is not planned.  What we might do is forcing new
users to be marked as external, which disallows them to do anything.
However, I don't know how a moderation workflow should work.

Currently the homegrown self-service thingy makes automatic signup
unlikely, but this will go away.

Salsa itself is also a pretty small target, as almost all content is
exempted from indexing.  And cleaning up is pretty easy.

The only types of spam we had was
- snippets in vietnamese and
- issues in vietnamese.

>                         One very nice aspect of the wiki signup
> moderation is that the team can respond to aspects of the signup
> email, welcoming the applicant with pointers to documentation,
> suggestions of ideas on how to help, mailing lists to join and so on.

How many new users per day do you get?

> Is there anything else that service admins need to be aware of?

Yes.  Please don't use the username (the field is called "nickname"),
but only the subject (the field is called "sub") to identify users.

Regards,
Bastian

-- 
First study the enemy.  Seek weakness.
		-- Romulan Commander, "Balance of Terror", stardate 1709.2

[toc] | [prev] | [next] | [standalone]

#11603

On Tue, Apr 7, 2020 at 6:23 PM Bastian Blank wrote:

> No, not really.  The services ask the SSO service for the identity of
> the user and get an attestation back.  So each service needs to handle
> it's own login.

Hmm, the OIDC documentation I've been able to find seemed to indicate
the login request on a service gets redirected to the OIDC provider,
which then redirects back to the service.

Is there any documentation and diagrams on the typical request flows
between the browser the servers involved that happens with OIDC?

Is there an OIDC demo site somewhere so that I can see the requests
between the browser and the servers involved and see which browser
features OIDC uses and requires in practice?

> However, I don't know how a moderation workflow should work.

I'd like to see this happen via a "welcome" team. You register an
account with a paragraph about why you're signing up, your account
gets moderated and you receive a welcome email from the team with tips
related to your signup paragraph and to the service where you started
the registration flow, for eg people starting their registration on
the wiki might get a link to the wiki editor guide.

https://wiki.debian.org/Welcome

> How many new users per day do you get?

Usually one or two users per day to moderate between Steve and myself,
sometimes more, especially during events. Our setup is less optimal
for people who don't have email addresses or read errors so there are
probably some who aren't contacting us to get an account. Also, to
reduce friction for existing FLOSS folks we have a list of related
email domains that do not need prior approval.

Do we know which other FLOSS related groups Debian's OIDC setup could
leverage for additional context at initial account creation? Or are we
thinking that we would use email, GitHub, GitLab, Twitter, Facebook
etc for that?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#11604

[Multipart message — attachments visible in raw view] — view raw

On Wed, Apr 08, 2020 at 04:51:49AM +0000, Paul Wise wrote:

> Is there any documentation and diagrams on the typical request flows
> between the browser the servers involved that happens with OIDC?
> Is there an OIDC demo site somewhere so that I can see the requests
> between the browser and the servers involved and see which browser
> features OIDC uses and requires in practice?

My goal in this discussion is to see if there are blockers for moving in
the direction that me and Waldi proposed, or to discover unexpected ways
in which what we propose would make the situation worse than it is now.

I would like to keep this discussion focused on ACK/NACK, so that me and
waldi and whoever may want to join the work, can go ahead and start
putting together implementation schedule and get things moving.

Are your questions an expression of curiosity about the OIDC protocol,
or about hinting that there is something there that you consider a
blocker to be discussed before we start working?


> > However, I don't know how a moderation workflow should work.
> 
> I'd like to see this happen via a "welcome" team. You register an
> account with a paragraph about why you're signing up, your account
> gets moderated and you receive a welcome email from the team with tips
> related to your signup paragraph and to the service where you started
> the registration flow, for eg people starting their registration on
> the wiki might get a link to the wiki editor guide.
> 
> https://wiki.debian.org/Welcome

I would definitely like to see the Welcome Team take off, and I would
prefer not to derail what seems like a workable plan about improving the
broken Single Sign-On situation, into a discussion about a Debian
Welcome Team.

I'd love to have a healty, active, and pervasive Welcome Team, and maybe
Salsa's an excellent opportunity for Welcome Team contributions.

Unless you think having a functional Welcome Team onboard should be
considered a blocker for moving on with SSO improvements, could we
postpone this to a later point?


I'd like to keep this round of discussion focused on two points:

 - is the current situation broken?
 - with this proposal, does it become less broken? 

That the current situation is broken seems to be generally agreed.

I haven't yet seen anything that convinced me that what we are proposing
would make it more broken, or would prevent further opportunities for
moving on.

If no serious blockers show up, in a few days I would start to go ahead.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11605

[Multipart message — attachments visible in raw view] — view raw

TL;DR: In Enrico's terms I'm an ACK not a NACK.  I'm also trying to help
people considering whether they have blocking objections think about the
problems actually facing Debian.


I'm noticing a bit of a conflict here between people who are familiar
with Debian and people who are familiar with SSO.

I think I have a bit of background in the SSO space over the years, and
can perhaps try and bridge the gap of understanding.

In a lot of SSO situations, the organization has a existing account
lifecycle management strategy, and the SSO situation is assisting that.

That is, the organization has a existing way to create accounts and deal
with entitlements for those accounts.

My day job uses Keycloak for that both for our own stuff and with
customers.  (We use a few other things in certain circumstances,
including amusingly enough Gitlab in one instance) but generally tend
toward Keycloak.

However, that doesn't really describe the Debian situation.

Debian has two account life cycle work flows that we're reasonably happy
with (or at least not proposing to change now).

The first is the account life cycle for developers.  DAM sends a signed
ticket to keyring-maint and DSA, and accounts get created or locked.
Developers send signed tickets to some combination of folks to deal with
name changes.

There's another flow.  Contributors interact with DSA in some process I
do not fully understand to get guest accounts on porter boxes etc.

These account life cycle flows are too heavy-weight for several tasks
that we find:

* someone wants an account on salsa for hosting projects or interacting
  with projects there.

* Someone wants to manage their contributors.debian.org info

* Someone wants to enter the nm process.  (This will eventually get to
  the heavy weight account life cycle, but  we want starting the
  application to involve zero signed RT tickets)

* People want to run services that consume Debian community accounts.

So, it's not just that we need an SSO provider.
we need a light weight account life cycle system that will fit into our
SSO strategy.

It also needs to eventually interact with nm, which will allow it to
work with the existing account life cycle flow for developer accounts.
But given Enrico's interest, I think it's safe to say that nm
interactions are being considered.

so, a lot of people are jumping up and down talking about particular SSO
strategies focusing on the SSO aspects of those strategies.

Where as what is the most important gaps for our project surround the
account life cycle stuff.

And for all its faults, Gitlab has a very easy story for this.

You can maintain an account in gitlab with a username and password.

In the long run you can also front gitlab with something else provided
that  you have a something else that does account lifecycle management.

As a reminder, no one is talking about having DSA trust gitlab to
control access to the archive or Debian machines.
I think we all cringe thinking about that.


--Sam

[toc] | [prev] | [next] | [standalone]

#11625

On Wed, Apr 08, 2020 at 06:23:29AM -0400, Sam Hartman wrote:
> Debian has two account life cycle work flows that we're reasonably happy
> with (or at least not proposing to change now).
> 
> The first is the account life cycle for developers.  DAM sends a signed
> ticket to keyring-maint and DSA, and accounts get created or locked.
> Developers send signed tickets to some combination of folks to deal with
> name changes.
> 
> There's another flow.  Contributors interact with DSA in some process I
> do not fully understand to get guest accounts on porter boxes etc.

The third flow being 'guests' in Debian LDAP.

> These account life cycle flows are too heavy-weight for several tasks
> that we find:
> 
> * someone wants an account on salsa for hosting projects or interacting
>   with projects there.
> 
> * Someone wants to manage their contributors.debian.org info
> 
> * Someone wants to enter the nm process.  (This will eventually get to
>   the heavy weight account life cycle, but  we want starting the
>   application to involve zero signed RT tickets)
> 
> * People want to run services that consume Debian community accounts.
> 
> So, it's not just that we need an SSO provider.
> we need a light weight account life cycle system that will fit into our
> SSO strategy.

With keycloak (or LLNG) set up as as a broker, then user account
self-creation is possible (caveat waldi's comments about attrs and
groups which requires more investigation).

> It also needs to eventually interact with nm, which will allow it to
> work with the existing account life cycle flow for developer accounts.
> But given Enrico's interest, I think it's safe to say that nm
> interactions are being considered.

With keycloak, when a user becomes a DD, we add an LDAP account and ask
the user to merge on next login via keycloak workflows or we use
keycloak APIs to merge for them.

> so, a lot of people are jumping up and down talking about particular SSO
> strategies focusing on the SSO aspects of those strategies.

No one is jumping, thank you.

> Where as what is the most important gaps for our project surround the
> account life cycle stuff.
> 
> And for all its faults, Gitlab has a very easy story for this.
> 
> You can maintain an account in gitlab with a username and password.
> 
> In the long run you can also front gitlab with something else provided
> that  you have a something else that does account lifecycle
> management.
> 
> As a reminder, no one is talking about having DSA trust gitlab to
> control access to the archive or Debian machines.  I think we all
> cringe thinking about that.

Well, given this DPL statement, shall I continue answering other emails
in this thread or no? That is the question now.

-- 
Luca Filipozzi

[toc] | [prev] | [next] | [standalone]

#11628

]] Sam Hartman 

> There's another flow.  Contributors interact with DSA in some process I
> do not fully understand to get guest accounts on porter boxes etc.

https://dsa.debian.org/doc/guest-account/

I'd like to see a proposal on how to avoid namespace clashes between
guest and non-DD salsa accounts?

(There's also the wiki account lifecycle, but that's completely separate
and doesn't interact with any of the others, so we might want to keep
that outside the discussion for now.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#11629

On Wed, Apr 08, 2020 at 08:50:00PM +0200, Tollef Fog Heen wrote:
>
>(There's also the wiki account lifecycle, but that's completely separate
>and doesn't interact with any of the others, so we might want to keep
>that outside the discussion for now.)

Agreed! (as a wiki admin)

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

[toc] | [prev] | [next] | [standalone]

#11631

[Multipart message — attachments visible in raw view] — view raw

On Wed, Apr 08, 2020 at 08:50:00PM +0200, Tollef Fog Heen wrote:

> > There's another flow.  Contributors interact with DSA in some process I
> > do not fully understand to get guest accounts on porter boxes etc.
> 
> https://dsa.debian.org/doc/guest-account/
> 
> I'd like to see a proposal on how to avoid namespace clashes between
> guest and non-DD salsa accounts?

For guest accounts opened on request via nm.debian.org, the idea is
requesting an account name that is the same as the Salsa account name.
Any requirement mismatches can be fixed by renaming the Salsa account
name prior to LDAP account creation.

For guest accounts opened by DSA directly, it can be pretty much the
same: you can use the current Salsa account name of the person as the
username for the guest account.

In case later a person decides to rename their Salsa account after
having a corresponding one in LDAP, see 20200408130828.izn7jdyufch7kfsc@enricozini.org


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11635

]] Enrico Zini 

> For guest accounts opened by DSA directly, it can be pretty much the
> same: you can use the current Salsa account name of the person as the
> username for the guest account.

I don't think we want to make the Debian LDAP service subservient to
salsa's, which this effectively would.  (People requesting guest
accounts might also not have salsa accounts.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#11636

[Multipart message — attachments visible in raw view] — view raw

On Thu, Apr 09, 2020 at 07:46:21PM +0200, Tollef Fog Heen wrote:

> > For guest accounts opened by DSA directly, it can be pretty much the
> > same: you can use the current Salsa account name of the person as the
> > username for the guest account.
> 
> I don't think we want to make the Debian LDAP service subservient to
> salsa's, which this effectively would.  (People requesting guest
> accounts might also not have salsa accounts.)

You don't have to, and I wouldn't consider LDAP subservient to anything:
if you create an account in LDAP that exists on Salsa, when the Salsa
user wants a guest account or to become DD, we'll ask them to rename
their Salsa account because the LDAP one is already taken.

The idea is to leave DSA free to implement whatever policy they want and
manage their LDAP namespaces as they see fit. When people want to create
accounts in them, they adapt according to the rules DSA sets.
nm.debian.org tries to validate as much as possible according to those
rules, to make thinks smoother. What we can't validate, we deal with it
on a case by case basis.

This is pretty much what what happens today: DSA gets to refuse (and
does refuse) account names arbitrarily without providing explanations
even when we ask, and we suck it up and deal with it. This is not
something we outside DSA can change, and it's not something I expect
will change.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11637

>>>>> "Tollef" == Tollef Fog Heen <tfheen@err.no> writes:

    Tollef> ]] Enrico Zini
    >> For guest accounts opened by DSA directly, it can be pretty much

First, at this point in time I would be very skepticle of someone
contributing to Debian enough to need porter box access but not having a
salsa account.
It's possible, but  that would be a yellow flag for me in evaluating
such a request.

There are two ways I might read the above statement.
First, subservient might mean that  you're worried about an attack on
salsa propagating into DSA's LDAP.
Clearly that would be bad.
So, taking an automated data feed from salsa and acting on it is
something we'd want to view with hesitation if not out right concern.

However, as I read the guest account process, it has a number of manual
steps where people are processing tickets.
I suspect that DSA actually has a script or set of scripts that go
create the guest account.

Having these scripts check to see if the name is registered at salsa and
requiring manual override to create an account if it conflicts with
salsa and appears to belong to a different user is not, in my mind,
making DSA's ldap subservient to the salsa LDAP.

It might be making one of the namespaces DSA controls interact with a
larger overlapping namespace.
It won't stop DSA from doing anything.
In fact, Enrico has demonstrated that even if DSA chooses to ignore this
project or to create conflicts everything will work out with annoyance
felt mostly be the people who are involved in a conflict.
But like the rest of us, members of DSA can register salsa accounts.
(And if DSA needed additional mechanisms to register salsa accounts, I
strongly suspect the salsa admins would cooperate in creating such a
mechanism.  If not, that sounds like something to escalate.)

I think this sort of namespace interaction--trying to have fewer
namespaces in the project and increase the chances that usernames in one
part of the project overlap with another--is a good thing.

And honestly, LDAP already is subservient to salsa in that game.
People interact with salsa far before they are going to interact with
DSA LDAP.
So much of what we do is based on salsa, and that's even more true for
many of the ways initial contributors can get involved with the project.

It is almost certain that your salsa account is the first Debian account
you will need.
Even if we have some SSO solution--even if we have some other account
lifecycle  process you go through to get your salsa account, you'll be
going through that process first because you want a salsa account.
Yes, it's Debian.
There will doubtless be exceptions: we have exceptions to everything.

But salsa accounts are the accounts people first run into in the vast
majority of cases.
And if you buy the argument that people's usernames should not change
as their role in the organization changes, the LDAP namespace is already
de facto subservient to the salsa namespace.
Any of the cases where that's not true are cases that frustrate and get
in the way of people trying to contribute to our community.

If you don't buy that argument--if you believe that -guest is a feature
rather than a bug, then things are more complicated.
However, assuming that the mechanisms for determining easily if someone
are a dd are adequate, I think there is a rough consensus in this
discussion that keeping the same username as your role changes is
desirable.


--Sam

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | linux.debian.project

csiph-web