Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Peter" == Peter Palfrader  writes:

Peter> On Mon, 13 Apr 2020, Sam Hartman wrote:
>> > "Luca" == Luca Filipozzi  writes:
>> 
Luca> This is why having a central approach to account creation,
Luca> rather than distributed, is worth considering. I'm in favour
Luca> of usernames not changing because one's role changes but that
Luca> does not mean I'm favour of divergent namespaces.
>> 
>> I don't think anyone here is in favor of divergent namespaces.  I
>> think a lot of us think it would be reasonable if salsa became
>> the place at which names were reserved

Peter> Except it's a huge, intensely integrated code-base that
Peter> currently is very hip.  Just like alioth was a few years ago.
Peter> Small is beautiful.

I'm sorry, I don't understand your point at all.
Right now, we are quite dependent on salsa.
Checking salsa for whether a name is reserved  and reserving that name
if it is not is an operation that can be abstractly contained.

Yes, that means if we move away from salsa we either need to:

1) provide a new implementation of that conceptual interface.  If nm and
DSA are the only consumers of the interface, the details can entirely
change, but the idea that we'll need to be able to check namespace
availability and reserve a name  will remain

or

2) At that point accept some level of namespace divergence.  There are
lots of ways of doing this, but I doubt we'd pick option two so I'm not
going to focus on it.

Yes, absolutely, salsa is big.
But abstractions are great because they allow us to isolate one part of
a system from another; they can isolate DSA and NM from various aspects
of salsa's bigness.

Yes, various parts of the project are saying that they want to have
usernames stay consistent enough that they are willing to accept the
technical debt of some interface going forward for figuring out if a
name is reserved and reserving that name.
And that today salsa seems like a good place to put the implementation
of that interface.
That's very very very different than getting stuck with salsa's bigness
on an ongoing basis.

--Sam

Re: Salsa as authentication provider for Debian

[Peter Palfrader]

On Mon, 13 Apr 2020, Sam Hartman wrote:

> > "Luca" == Luca Filipozzi  writes:
> 
> Luca> This is why having a central approach to account creation,
> Luca> rather than distributed, is worth considering. I'm in favour
> Luca> of usernames not changing because one's role changes but that
> Luca> does not mean I'm favour of divergent namespaces.
> 
> I don't think anyone here is in favor of divergent namespaces.  I think
> a lot of us think it would be reasonable if salsa became the place at
> which names were reserved

Except it's a huge, intensely integrated code-base that currently is
very hip.  Just like alioth was a few years ago.  Small is beautiful.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Re: Salsa as authentication provider for Debian

[Pirate Praveen]

On Mon, Apr 13, 2020 at 6:39 pm, Tollef Fog Heen  wrote:

It's not clear to me why removing the -guest restriction has to happen
for sso.d.o to be using Salsa as an IdP, which seems to be your 
primary
goal?  That's my most immediate concern.  Switching to oauth2/OIDC 
seems

like a good idea, and assuming we can move to another broker somewhere
down the line, I have no problems with that happening.



This was already answered here,

https://lists.debian.org/debian-project/2020/04/msg00031.html

On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

No.  The guest suffix was meant to avoid collisions with Debian
accounts.  And the tool used to enforce it is unmaintained.

Also the only place that can for sure answer if someone is DD is
nm.debian.org, not Salsa.

Re: Salsa as authentication provider for Debian

[Tollef Fog Heen]

]] Enrico Zini 

> On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote:
> 
> > We quite regularly have upstreams getting access for weird architecture
> > failures.  There's no particular reason for those people to have salsa
> > accounts.
> 
> I understand those are temporary accounts. Do those cases need an
> arbitrary name from the LDAP namespace?
> 
> Several places I worked with use a pool of time-limited accounts from a
> guestNNN namespace, for example: that could address your use case
> without overlapping with anything else.

We have guest accounts that have been in use longer than the lifecycle
of some DD accounts, so while it would technically work, it wouldn't be
a particularly nice solution.  (You can of course say that requiring
non-DDs registering on salsa to have a -guest suffix isn't nice either,
something I can agree with.)

> > It does to me, since suddenly we have to care about what's on salsa,
> > something we've never had to care about before.
> 
> As I said in 20200409181701.3qqsn5sqq3xbu...@enricozini.org, no, you
> don't need to care about anything: you keep doing what you want, and we
> deal with it.

I think we in practice will want to do that in order to avoid triggering
bugs in software that assumes that user names are consistent.

> So far, I only received requests to keep the status quo as it is
> indefinitely, and very little in terms of counterprosals actionable now,
> besides theoretical new software solutions to be explored, that would
> address the problems I am having.

In case that was directed at me, rather than the wider world: I'm not
requesting you do one thing or another, I'm pointing out some possible
ramifications.

It's not clear to me why removing the -guest restriction has to happen
for sso.d.o to be using Salsa as an IdP, which seems to be your primary
goal?  That's my most immediate concern.  Switching to oauth2/OIDC seems
like a good idea, and assuming we can move to another broker somewhere
down the line, I have no problems with that happening.

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

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Luca" == Luca Filipozzi  writes:

Luca> This is why having a central approach to account creation,
Luca> rather than distributed, is worth considering. I'm in favour
Luca> of usernames not changing because one's role changes but that
Luca> does not mean I'm favour of divergent namespaces.

I don't think anyone here is in favor of divergent namespaces.  I think
a lot of us think it would be reasonable if salsa became the place at
which names were reserved, probably at first as a matter of practice,
and eventually as other parts of the project sign on over time, with
appropriate auditing and checking.  The other activities that involve
namespace reservations all seem to have a manual component, removing
security concerns that might exist if there was an automated data feed
from salsa that was automatically imported into other parts of the
namespace.

Other solutions would also be reasonable over time.

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote:

> We quite regularly have upstreams getting access for weird architecture
> failures.  There's no particular reason for those people to have salsa
> accounts.

I understand those are temporary accounts. Do those cases need an
arbitrary name from the LDAP namespace?

Several places I worked with use a pool of time-limited accounts from a
guestNNN namespace, for example: that could address your use case
without overlapping with anything else.


> It does to me, since suddenly we have to care about what's on salsa,
> something we've never had to care about before.

As I said in 20200409181701.3qqsn5sqq3xbu...@enricozini.org, no, you
don't need to care about anything: you keep doing what you want, and we
deal with it.


So far, I only received requests to keep the status quo as it is
indefinitely, and very little in terms of counterprosals actionable now,
besides theoretical new software solutions to be explored, that would
address the problems I am having.

I want to be very clear on this: I have no intention of keeping the
status quo as it is now: either it becomes something that I can manage,
or I'll stop managing it.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Sun, Apr 12, 2020 at 08:21:49AM +0300, Andrei POPESCU wrote:
> On Sb, 11 apr 20, 19:27:53, Julien Cristau wrote:
> > On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
> > > 
> > > I must be missing something so I'm asking: what is the *benefit* of 
> > > avoiding collisions with Debian accounts?
> > > 
> > f...@salsa.debian.org and f...@debian.org both existing and referring to
> > different people risks causing confusion.  I'd like to understand why
> > we're going that way.
> 
> If I understand correctly, then, using the -guest suffix would allow for 
> foo-gu...@salsa.debian.org and f...@debian.org both existing and 
> referring to different people.
> 
> In my opinion this still doesn't significantly reduce the risk of 
> confusion while also being quite unfriendly should the foo-guest user 
> ever wish to become a Debian Member.

This is why having a central approach to account creation, rather than
distributed, is worth considering. I'm in favour of usernames not
changing because one's role changes but that does not mean I'm favour of
divergent namespaces.

-- 
Luca Filipozzi


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Tollef Fog Heen]

]] Sam Hartman 

> > "Tollef" == Tollef Fog Heen  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.

We quite regularly have upstreams getting access for weird architecture
failures.  There's no particular reason for those people to have salsa
accounts.

> 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.

That varies.  It's LDAP, people sometimes use the ud-* suite of tools,
sometimes ldapvi.  Is salsa also going to check for debian.org accounts
when creating and renaming accounts on its side?

> 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.

(Salsa doesn't use LDAP, afaik)

It does to me, since suddenly we have to care about what's on salsa,
something we've never had to care about before.  It also breaks the
invariant people have been able to trust so far, that foo@salsa.d.o is
also foo@d.o (assuming both exist).  This will no longer hold true, and
I think we'll run into security problems down the line because of it.

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

Re: Salsa as authentication provider for Debian

[Andrei POPESCU]

On Sb, 11 apr 20, 19:27:53, Julien Cristau wrote:
> On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
> > 
> > I must be missing something so I'm asking: what is the *benefit* of 
> > avoiding collisions with Debian accounts?
> > 
> f...@salsa.debian.org and f...@debian.org both existing and referring to
> different people risks causing confusion.  I'd like to understand why
> we're going that way.

If I understand correctly, then, using the -guest suffix would allow for 
foo-gu...@salsa.debian.org and f...@debian.org both existing and 
referring to different people.

In my opinion this still doesn't significantly reduce the risk of 
confusion while also being quite unfriendly should the foo-guest user 
ever wish to become a Debian Member.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Michael" == Michael Lustfield  writes:

Michael> Multiple concerns have been raised and subsequently
Michael> shrugged off. It's clear that no concern raised will make
Michael> any difference so, yeah... go for it.

Actually, Enrico provided a summary describing how the concerns that
have been raised have been evaluated; see
20200410183809.nchdmlkk6zdj7...@enricozini.org .

That message demonstrates changes that have been made in response to
concerns raised.
The primary example is better ability to figure out from a salsa user
page who is a DD.

It also explains the analysis of the other issues that were raised.
Significant effort was put into evaluating the concerns raised by Enrico
and others.

I appreciate your frustration, but your message crossed a line that I
would ask you not to cross again.
I would urge you to find a way to disagree with decisions and express
frustration without undermining the work of others.

I hear your desire to design a solution and get a project wide consensus
on that solution.
Long term, perhaps we'll do that.
However, Debian empowers maintainers of groups within our project to
move forward; Debian values incremental development; and Debian values
letting people actively doing the work have significant latitude in how
that work is done.

I think the bar for halting people  going forward and making things
incrementally better is very high, and no, my take as someone who has
facilitated a lot of discussions is that none of the concerns raised met
that bar.

Things might be different if Enrico's decisions or work blocked other
people from going forward andexploring their own (potentially
longer-term) options.

That's not the case.

Much of the work Enrico proposes to do--for example adopting OIDC for
sso.debian.org and nm.debian.org--is common across all the solutions.

There have been a number of people who have looked at the work involved
in changing from one IDP (salsa) to another and concluded that it is
well within the sorts of changes we've made in Debian's sso architecture
over the years.
Independently of Enrico's proposal, and unremarked by everyone who is in
this discussion, debian.social has adopted the same strategy.
Even if nm.debian.org, contributors.debian.org and sso.debian.org were
not going to use salsa, we'd already have salsa being used as a sso
solution within Debian.





Sam Hartman
Debian Project Leader


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Julien" == Julien Cristau  writes:

Julien> On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
>> 
Julien> f...@salsa.debian.org and f...@debian.org both existing and
Julien> referring to different people risks causing confusion.  I'd
Julien> like to understand why we're going that way.

We aren't.
However, there has been an emerging project consensus that we do not
wish  for people's usernames (salsa or otherwise, but especially salsa)
to change as their role in the project changes.

I've been seening this come up again and again throughout my term as
DPL:

* Disabling people's ability to contribute to salsa when their account
  was suspended was a significant unintended consequence of DAM actions
  last year.  It created a lot of friction.

* That same friction appeared as pushback on recommending salsa in
  various ways.

* As a side thread on the Git Packaging discussion on debian-devel,
  there was a strong desire to improve this and get to a position where
  -guest accounts didn't work the way they do today.  I did not directly
  report on that in my consensus call because it was out of scope, but
  as the person facilitating that discussion, I think we had a
  presumptive consensus in favor of moving in that direction.

* The issues with -guest accounts did impact the consensus call for the
  Git Packaging discussion in that we had fewer options to recommend for
  non-DDs starting out packaging.  People felt uncomfortable
  recommending a -guest name for packaging, and the account lifecycle
  issues significantly complicated that discussion.

* It's my reading of the thread here that there was again a rough
  consensus in favor of not having usernames change as your role in the
  project changes.  Multiple arguments have been advanced and  it
  appears the rough consensus of the discussion here is in favor of the
  change.

Your concern--about  foo@salsa and f...@debian.org both existing has been
discussed.
It's clear there is a desire to minimize this.
At least for the pathways involving nm.debian.org, my understanding is
that we will avoid this.
by requiring that people register a salsa account before obtaining a DSA
guest account, DSA could choose to close off the remaining ways in which
this conflict emerges.

Obviously, the salsa maintainers and nm maintainers don't have the power
to make this happen.  They have managed the risk in the areas where they
can and have notified everyone of the issue.

My suspicion is that the project will conclude that even given a
residual risk if DSA were not to choose to act, the advantages of having
usernames not change is sufficient that the project is unwilling to try
to override the salsa maintainers.

--Sam


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Julien Cristau]

On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
> On Mi, 08 apr 20, 19:40:27, Julien Cristau wrote:
> > On Wed, Apr  8, 2020 at 14:30:43 +0200, Bastian Blank wrote:
> > 
> > > Hi Zhu
> > > 
> > > On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > > > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > > > recognize who is DD or not on salsa?
> > > 
> > > No.  The guest suffix was meant to avoid collisions with Debian
> > > accounts.  And the tool used to enforce it is unmaintained.
> > > 
> > I think avoiding collisions with debian accounts is still valuable, and
> > the proposal doesn't explain why removing this protection is in any way
> > related or necessary for other services to use salsa as auth providers.
> 
> I must be missing something so I'm asking: what is the *benefit* of 
> avoiding collisions with Debian accounts?
> 
f...@salsa.debian.org and f...@debian.org both existing and referring to
different people risks causing confusion.  I'd like to understand why
we're going that way.

Cheers,
Julien

Re: Salsa as authentication provider for Debian

[Michael Lustfield]

On Sat, 11 Apr 2020 12:02:40 +0200
Jonathan Carter  wrote:

> [...]
> This thread has had lots of discussion so far and no one has listed a
> single reason against your proposal yet, IMHO if no one is standing in
> your way it's time to just go ahead and do it.

Multiple concerns have been raised and subsequently shrugged off. It's clear
that no concern raised will make any difference so, yeah... go for it. There's
no point continuing typical debian drama for something that's going to be
pushed forward regardless.

Re: Salsa as authentication provider for Debian

[Jonathan Carter]

On 2020/04/10 13:05, Felix Lechner wrote:
> As a group, we are driving Enrico up the wall. Let's just get rid of
> the old stuff now
...

+1

Enrico, your plans sound very sane and from all the information in these
threads it seems logical for the project to go ahead with it.

What's holding you back at this point? From the initial post from
Bastian it does seem that most stakeholders on the admin side have been
involved and that they may be on board. I know the salsa admins have
been (understandably) reluctant to just jump in on this in the past,
have you heard back from them and are they supportive of your idea for
the reasons you have listed?

This thread has had lots of discussion so far and no one has listed a
single reason against your proposal yet, IMHO if no one is standing in
your way it's time to just go ahead and do it.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Salsa as authentication provider for Debian

[Andrei POPESCU]

On Mi, 08 apr 20, 19:40:27, Julien Cristau wrote:
> On Wed, Apr  8, 2020 at 14:30:43 +0200, Bastian Blank wrote:
> 
> > Hi Zhu
> > 
> > On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > > recognize who is DD or not on salsa?
> > 
> > No.  The guest suffix was meant to avoid collisions with Debian
> > accounts.  And the tool used to enforce it is unmaintained.
> > 
> I think avoiding collisions with debian accounts is still valuable, and
> the proposal doesn't explain why removing this protection is in any way
> related or necessary for other services to use salsa as auth providers.

I must be missing something so I'm asking: what is the *benefit* of 
avoiding collisions with Debian accounts?

While I'm at it, in my opinion as a non-Debian Member, getting rid of 
the -guest suffix is also slightly more welcoming for new contributors.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[kuLa]

On 10 April 2020 12:05:42 BST, Felix Lechner  wrote:
>Hi,
>
>As a group, we are driving Enrico up the wall. Let's just get rid of
>the old stuff now and have a discussion about keycloak and
>lemonldap-ng at the same time.

I fully support this statement also please remember that  perfect is the enemy 
of good.

Waldi and Enrico presented a good and viable solution for existing situation 
which is not blocking nor forbidding anybody to work on another approach in the 
future.

I understand that there is big appetite from DSA and others to implement 
comprehensive and maintainable ID and user management in Debian.
As far as I'm able to understand presented proposal there is nothing in it that 
would prevent future or even parallel implementation of other solutions.

So, please people let them do what they proposed and in the mean time work on 
the future solution which could be plugged in to what will emerge after Enrico 
and Waldi are done.

kula

Re: Salsa as authentication provider for Debian

[Russ Allbery]

Luca Filipozzi  writes:

> I think that our services -- such as SCM, CI/CD, Wiki, RT, etc. --
> should evolve indepdently from the SSO infrastructure. One could argue
> that RT has a user database thatcould be used as authenticaion service
> if exposed correctly. Or the Wiki.

Let me try to rephase this and see if I understand.  Your concern is that
by using Salsa as the IdP, we're coupling identity in Debian too closely
to one component of our development infrastructure, and thus possibly
creating roadblocks in the future?  For example, we might want to switch
to a different SCM platform that doesn't provide an IdP, or we may want
IdP features that aren't a priority for GitLab?

That argument does make sense to me.  This path more tightly couples the
project to the Salsa deployment.

However, I personally am not *too* worried about this because OIDC makes
it possible to migrate IdPs without too many problems.  This is where a
standardized protocol helps considerably.  There would still be some
challenges in exporting and converting the Salsa identity database, but we
have all that data and could do that work.

I agree with you that this is a risk, and it might be good to do some
planning work up-front to identify the data we're storing in Salsa that we
may want to move to some other platform like Keycloak in the future, but I
think it's a risk we can mitigate.

-- 
Russ Allbery (r...@debian.org)  

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Fri, Apr 10, 2020 at 02:08:01PM -0400, Sam Hartman wrote:
> > "Russ" == Russ Allbery  writes:
> 
> Russ> Luca Filipozzi  writes:
> >> On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:
> 
> >>> * Note that if you want to you can host accounts in gitlab and
> >>> have keycloak act as an OIDC consumer for gitlab.  So, if you
> >>> decide you like Gitlab as an IDP but find you need Keycloak's
> >>> transformations, you can have people login to Keycloak using
> >>> their Gitlab accounts.
> 
> >> I reiterate my point that an SP being an IdP. I don't view using
> >> Debian's Gitlab as an IdP to be a prudent move.
> 
> Russ> I don't understand this objection.  The relying party and the
> Russ> identity provider are certainly different components with
> Russ> different functions, but that doesn't imply that they can't be
> Russ> combined in the same software suite.  There's quite a lot of
> Russ> shared code between an SP and an IdP, so in some sense that's
> Russ> easier than maintaining them as entirely separate projects.
> 
> I echo Russ's thoughts exactly.
> Russ and I both have a long history in the SSO world, and I think that
> if two people who have history say "we don't see the objection," it's
> a good idea to explore your objection in significantly more detail than
> simply asserting it.

I'm not saying that gitlab's IdP implementation is poor (another thread:
is discussing it's quality, however). The fact that gitlab shares code
between SP and IdP is not my concern.

Let me be more precise: I'm talking about the service itself and not
about the SP.

I think that our services -- such as SCM, CI/CD, Wiki, RT, etc. --
should evolve indepdently from the SSO infrastructure. One could argue
that RT has a user database thatcould be used as authenticaion service
if exposed correctly. Or the Wiki.

Some organizations use their mailing list system (sympa, in particular)
as their group management solution.

None of this coupling between user management, group management,
authentication services and a specific service strikes me as prudent.

My observation is strictly related to the coupling of these things.

If I'm the only one with this concern, so be it.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Felix Lechner]

Hi,

On Fri, Apr 10, 2020 at 12:49 AM Enrico Zini  wrote:
>
> The current sso.debian.org codebase has been written by one person (me),
> deployed by one person (me), audited by nobody, and as far as I'm aware,
> nobody besides me has ever read the code.

As a group, we are driving Enrico up the wall. Let's just get rid of
the old stuff now and have a discussion about keycloak and
lemonldap-ng at the same time.

Kind regards
Felix Lechner

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 02:23:47PM +0200, Ole Streicher wrote:

> I don't know the exact proposed rules here, but I could imagine that
> without these rules anyone cann fill the namespace of nice Debian user
> names.

If you're talking spam account flooding the namespaces, they can be
cleaned up from time to time.

If you're talking about legitimate Debian contributors not yet
interested in becoming DDs, using up names that people interested now in
becoming DDs would like to have, I think it's not a problem if the
people who registered the name first gets to keep it.


> And there is the danger that someone hijacks the user name of a
> Debian user who is still not on Salsa. Or an emeritus name or so.

The proposed workflow is that:

 - you register a name on Salsa
 - after you go through nm.d.o, it becomes your name on LDAP

By default, when you become a DD you have the same username on Salsa,
and so it's taken by you and nobody can register it, even if you become
emeritus.

If you decide to rename your Salsa account, then yes somebody else can
take it, and it's fair enough. If somebody takes it over maliciously,
the account can be locked.

If you decide to rename your account but don't want somebody else to
register your old name, you can register it yourself after the rename,
to keep control of it.


> I would also like to have a visible distinction between "trusted" names
> (where the owner is verified via key) and random names, in one way or
> the other.

The official membership status synced from nm.debian.org can, with some
work, be made visible in the user's page.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Julien Cristau]

On Wed, Apr  8, 2020 at 14:30:43 +0200, Bastian Blank wrote:

> Hi Zhu
> 
> On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
> 
> No.  The guest suffix was meant to avoid collisions with Debian
> accounts.  And the tool used to enforce it is unmaintained.
> 
I think avoiding collisions with debian accounts is still valuable, and
the proposal doesn't explain why removing this protection is in any way
related or necessary for other services to use salsa as auth providers.

What problem does the tool have that aren't being addressed?  I haven't
seen a call for help on this; can you give pointers?

Cheers,
Julien

Re: Salsa as authentication provider for Debian

[Xavier]

Le 07/04/2020 à 18:50, Sam Hartman a écrit :
>> "Xavier" == Xavier   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

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Luca Filipozzi  writes:
>> On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:

>>> * Note that if you want to you can host accounts in gitlab and
>>> have keycloak act as an OIDC consumer for gitlab.  So, if you
>>> decide you like Gitlab as an IDP but find you need Keycloak's
>>> transformations, you can have people login to Keycloak using
>>> their Gitlab accounts.

>> I reiterate my point that an SP being an IdP. I don't view using
>> Debian's Gitlab as an IdP to be a prudent move.

Russ> I don't understand this objection.  The relying party and the
Russ> identity provider are certainly different components with
Russ> different functions, but that doesn't imply that they can't be
Russ> combined in the same software suite.  There's quite a lot of
Russ> shared code between an SP and an IdP, so in some sense that's
Russ> easier than maintaining them as entirely separate projects.

I echo Russ's thoughts exactly.
Russ and I both have a long history in the SSO world, and I think that
if two people who have history say "we don't see the objection," it's
a good idea to explore your objection in significantly more detail than
simply asserting it.

--Sam

Re: Salsa as authentication provider for Debian

[Russ Allbery]

Luca Filipozzi  writes:
> On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:

>> * Note that if you want to you can host accounts in gitlab and have
>>   keycloak act as an OIDC consumer for gitlab.  So, if you decide you
>>   like Gitlab as an IDP but find you need Keycloak's transformations,
>>   you can have people login to Keycloak using their Gitlab accounts.

> I reiterate my point that an SP being an IdP. I don't view using
> Debian's Gitlab as an IdP to be a prudent move.

I don't understand this objection.  The relying party and the identity
provider are certainly different components with different functions, but
that doesn't imply that they can't be combined in the same software suite.
There's quite a lot of shared code between an SP and an IdP, so in some
sense that's easier than maintaining them as entirely separate projects.

-- 
Russ Allbery (r...@debian.org)  

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Fri, Apr 10, 2020 at 12:06:42PM +0200, Bastian Blank wrote:
> On Wed, Apr 08, 2020 at 03:18:58PM +, Luca Filipozzi wrote:
> > > - Salsa, how should it work together.
> > Gitlab can use OIDC as an OmniAuth provider.
> 
> And here the problems begin.
> 
> Sure, just using it as OmniAuth provider works.  But this only provides
> authentication.
> 
> But, as Sam correctly mentioned, as all others ignored it: we need
> user life cytle.  And just using OmniAith does not provide any life
> cycle control.
> 
> > > - Who is willing to maintain this long-term
> > I'm not committing DSA to this but I'm encouraged by their interest in a
> > demo.
> > There are at least three people on the thread who are familiary with
> > SAML/OIDC who are interested in supporting this service.
> 
> You are opting in to maintain three monsters:
> - Java
> - Wildfly
> - Keycloak

Java is already maintained by a team.

I'm not proposing to maintain wildfly independently from keycloak. I
appreciate that there's a 'vendor library' discussion here.

> > > What isn't so great
> > > - no particular good admin interface (there are 40+ settings for each
> > >   OIDC client alone)
> > 
> > Nearly all of those settings are auto-populated by exchanging metadata.
> > In SAML, the SP and the IdP exchange XML documents containing the
> > metadata. Tedious but works.  In OIDC, the SPI and the IdP point to each
> > other's 'well-known' configuration URLs to pull in the metadata. The
> > OIDC folks learned from SAML.
> 
> No, Keycloak is running as OIDC server in this case, so it _provides_
> all the settings via the metadata discovery mechanism.
> 
> It's just that the existence of most of those options negates the
> possibility to allow a random user to use it safely.

There are two things that I need to think about here:
(1) how to allow users to add SPs
(2) how hard is it to add SPs

> > > - it can have forms without a required field, which can't be saved at
> > >   all.
> > Not sure what you're describing, here.
> 
> Just random bugs.
> 
> - Enable "email as username"
> - Try to add a user by admin interface
> 
> > > - requires Java 8, which is not supported on Debian Buster
> > 
> > This isn't true. I'm running keycloak in a demo for work using
> > openjdk-11-jre-headless. Their documentation would do well to say
> > Java 8 or later.
> 
> The latest installation doc is pretty specific:
> 
> https://www.keycloak.org/docs/latest/server_installation/#system-requirements

Maybe I'll file a documentation bug seeking a correction.

Redhat have worked hard to keep wildfly operable on the latest GA java
version. In other words, keycloak9 on wildfly18 on java11. I expect that
kecloak10 on wildfly19 will be released soon: wildfly19 was released a
few weeks ago.

Their support for latest GA java will cease, temporarily, with java14
because they are still digesting the impact of package removals compared
to java11.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:
> * I was right.  Gitlab can work as an identity broker.  They
>   generally have people use keycloak to log into gitlab.  However, there
>   is one common app where it was easier to set up that app to consume
>   gitlab than keycloak so they did.

My point is that an SP shouldn't be an IdP nor an IdB. We should
separate these concerns.

> * This organization does not use keycloak to host accounts.  That is,
>   all the accounts are stored something else.  There are no locally
>   created keycloak accounts.

When operating as an IdB, there's always a local 'account'
represenatation in keycloak's DB. It contains the record that ties a
user to IdPs, and exposes a single user representation to to service
providers. A user might start their journey using a social identity and
then switch to a Debian identity. 

Debian LDAP
   |
   |
Debian IdP  --+ +-- Social IdP2
  | |
  IdB - Service Providers
  | |
Social IdP1 --+ +-- Social IdP3

(Sam: Above is an ASCII art diagram showing that Debian IdP and Social
IdPs would be tied into the IdB.)

That's different than enabling "local account", which we could leave
off. That would mean people would need a social identity to start with.

That said, keycloak does have a local user onboarding flow.

> * On the call, our suspicion is that gitlab is going to do a better job
>   of account lifecycle management than keycloak, but again, the
>   organization in question has not tried that with keycloak.  It seems
>   that having local accounts in Keycloak is not one of its most polished
>   features.  But again,  this is a guess without explicit experience.

I'd say that a proof of concept is needed.

> * Note that if you want to you can host accounts in gitlab and have
>   keycloak act as an OIDC consumer for gitlab.  So, if you decide you
>   like Gitlab as an IDP but find you need Keycloak's transformations,
>   you can have people login to Keycloak using their Gitlab accounts.

I reiterate my point that an SP being an IdP. I don't view using
Debian's Gitlab as an IdP to be a prudent move.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Sam Hartman]

Hi.  Speaking very much as an individual.

I just spoke  to someone  who runs a keycloak and gitlab instance for a
group of about 1000 users.
I wanted to inject their experience into the discussion, because  having
operational experience is useful in such situations.

* The thing they like about keycloak is the same thing people have
  mentioned here: it's a great identity broker.  It's really good at
  that, good at giving you all the options you might need.

* It works well with LDAP/AD/whatever account store you have.

* I was right.  Gitlab can work as an identity broker.  They
  generally have people use keycloak to log into gitlab.  However, there
  is one common app where it was easier to set up that app to consume
  gitlab than keycloak so they did.

* Gitlab is more limited in what it can do as an IDP or ID broker.  If
  it meets your needs, that's great; if not you may need something like
  keycloak.

* Migrating from gitlab to keycloak should not be a problem provided
  that you think about what you're going to use as primary keys so that
  accounts remain linked across the migration on the consumer side.

* This organization does not use keycloak to host accounts.  That is,
  all the accounts are stored something else.  There are no locally
  created keycloak accounts.

* On the call, our suspicion is that gitlab is going to do a better job
  of account lifecycle management than keycloak, but again, the
  organization in question has not tried that with keycloak.  It seems
  that having local accounts in Keycloak is not one of its most polished
  features.  But again,  this is a guess without explicit experience.

* Note that if you want to you can host accounts in gitlab and have
  keycloak act as an OIDC consumer for gitlab.  So, if you decide you
  like Gitlab as an IDP but find you need Keycloak's transformations,
  you can have people login to Keycloak using their Gitlab accounts.

* We did not discuss security.  Neither of us had audited either
  product.

--Sam

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Luca" == Luca Filipozzi  writes:

[All my statements in this thread have been as an individual, not as
DPL.  I've offered to help Enrico facilitate consensus calling in this
discussion, and if he takes me up on that, such facilitation might not
entirely be separable from the DPL role when done by the acting DPL.
]

>> the future?

Luca> I think introduction of the broker is the compelling use
Luca> case. I appreciate that you may not view that as sufficient
Luca> compelling.

I think you are arguing that something like keycloak is a broker, but
something like gitlab cannot be a broker.

That is not true in my experience.
One of my employer's customers uses keycloak as an IDP to log into
gitlab.
They then use gitlab as an application to front a few developer-facing
services.
So, in effect in that environment gitlab works as a broker.

I'd assume that you could just as easily permit people to use onmiauth
to Google on the gitlab side rather than fronting with keycloak.
So, I think we get broker aspects either way.

Now, doubtless keycloak is a more flexible broker than gitlab.
But as best I can tell broker is a use case that is present in all the
solutions being discussed.
I do not think it is unique to the llng/keycloak path.

Re: Salsa as authentication provider for Debian

[Bastian Blank]

Hi Luca

On Wed, Apr 08, 2020 at 03:18:58PM +, Luca Filipozzi wrote:
> > - Salsa, how should it work together.
> Gitlab can use OIDC as an OmniAuth provider.

And here the problems begin.

Sure, just using it as OmniAuth provider works.  But this only provides
authentication.

But, as Sam correctly mentioned, as all others ignored it: we need
user life cytle.  And just using OmniAith does not provide any life
cycle control.

> > - Who is willing to maintain this long-term
> I'm not committing DSA to this but I'm encouraged by their interest in a
> demo.
> There are at least three people on the thread who are familiary with
> SAML/OIDC who are interested in supporting this service.

You are opting in to maintain three monsters:
- Java
- Wildfly
- Keycloak

> > What isn't so great
> > - no particular good admin interface (there are 40+ settings for each
> >   OIDC client alone)
> 
> Nearly all of those settings are auto-populated by exchanging metadata.
> In SAML, the SP and the IdP exchange XML documents containing the
> metadata. Tedious but works.  In OIDC, the SPI and the IdP point to each
> other's 'well-known' configuration URLs to pull in the metadata. The
> OIDC folks learned from SAML.

No, Keycloak is running as OIDC server in this case, so it _provides_
all the settings via the metadata discovery mechanism.

It's just that the existence of most of those options negates the
possibility to allow a random user to use it safely.

> > - it can have forms without a required field, which can't be saved at
> >   all.
> Not sure what you're describing, here.

Just random bugs.

- Enable "email as username"
- Try to add a user by admin interface

> > - requires Java 8, which is not supported on Debian Buster
> 
> This isn't true. I'm running keycloak in a demo for work using 
> openjdk-11-jre-headless. Their documentation would do well to say Java 8 or 
> later.

The latest installation doc is pretty specific:

https://www.keycloak.org/docs/latest/server_installation/#system-requirements

Regards,
Bastian

-- 
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
-- Kirk, "Errand of Mercy", stardate 3198.4

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Fri, Apr 10, 2020 at 09:40:45AM +0200, Enrico Zini wrote:

> If you or someone else eventually will manage to introduce a Single Sign
> On system that would take us to a next step of being able to advocate
> developers, take packaging actions, update the ssh key you use to access
> debian.org machines, all via a web interface, I really look forward to
> that!

Incidentally, if you could eventually manage to make a viable proposal
for a SSO system that DSA and ftp-master considered secure enough to
enable building web UIs that could do things like, for example, but not
limited to:

 - advocate people on nm.d.o without needing to paste a
   GPG-inline-signed statement into a web form
 - move a package from experimental to unstable with one click
 - trigger a binNMU
 - vote for a GR by ranking options in a web form

Then I think that it would be a compelling enough innovation that you
won't have to be afraid of any amount of "good enough" for whatever
other system will be in place by then.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Mon, Apr 06, 2020 at 02:34:03PM -0500, Michael Lustfield wrote:

> I was previously involved with a company that audited various git-hosting
> services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so
> please forgive the lack of specifics. Gitlab is a tool that gets many things
> right, and many things wrong. Access control is an area where I have seen some
> critical bugs. Some of those bugs lead me to not trust it as a non-internal
> authentication source.

I normally assume anything with a huge codebase to be full of holes, so
I'd say you haven't told me anything surprising.

The current sso.debian.org codebase has been written by one person (me),
deployed by one person (me), audited by nobody, and as far as I'm aware,
nobody besides me has ever read the code. I think that's a scarier
picture than Gitlab: at least Gitlab is somehow widely deployed, has
regular updates, and has people maintaining it in production and sending
patches, which gives it a limited amount of scrutiny.

I still claim introducing gitlab as OIDC provider is not going to make
matters /worse/, and, I repeat, that's the only claim I've been trying
to get validated here.

If you are concerned that Debian critical operations could be depending
on a single signon platform which does not have the track record of
security that we would like, then we're already dealing with that: the
whole world controlled by sso.debian.org is designed under the
assumption of not being secure enough.

You can't get sso.debian.org access with your Debian master password:
you need a web password instead, which does not give you access to the
rest of db.debian.org.

With a sso certificate, for example, you can't change your status in
Debian, you can't advocate a person, you can't AM approve, you can't DAM
approve, you can't upload packages, you can't vote, you can't read
debian-private, you can't gain shell access to debian.org machines: we
require a GPG signature from a key in the Debian keyring for all those
operations. That is not going to change.

If you or someone else eventually will manage to introduce a Single Sign
On system that would take us to a next step of being able to advocate
developers, take packaging actions, update the ssh key you use to access
debian.org machines, all via a web interface, I really look forward to
that!

That's not what we're trying to do here. We're not there now, and it's
not going to change with introducing Salsa as an OIDC provider.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Thu, Apr 09, 2020 at 05:09:19AM -0500, Michael Lustfield wrote:

> It also appears that there is an intent to drop -guest naming. I haven't seen
> any technical discussion about this beyond learning about the current
> structure. I am very concerned that this will have significant consequences in
> regard to DSA-managed LDAP.

Are you concerned or do you have specific issues in mind?

Do you have actual issues that have not been addressed in
20200409072447.ci2xnvtnwv5as...@enricozini.org and
20200409181701.3qqsn5sqq3xbu...@enricozini.org ?


> Meanwhile, there are now five people with an interest in doing what we can to
> rectify the situation. It's unfortunate that we weren't aware of the stall a
> year ago, but we're here now, and I don't intend to work slowly. I'm confident
> you're aware of my "requirements gathering" phase. Design has been roughly
> discussed and I'm now taking a day to bury myself in documentation. Since I'm
> still playing the social distancing game, you can probably guess where my
> weekend priorities will be. :)

I don't know how many times I repeated that I have no intention of
standing in your way, I wish you great success, I look forward to having
a healthy and long-lived team that takes care of a great and official
Signle Sign On system in Debian. I *want* to be able to stop worrying
about this and focus on maintaining the services I need to maintain.

Could you please meanwhile not stand in the way of trying to fix the
status quo enough that I feel safe in keeping the services I maintain
online?

I've been in a horrible situation for more than a year waiting
helplessly for this to happen, and I have a chance to get out of that
pit while not getting in your way. Can you give me a good, practical
reason why you seem want me to stop with that?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Tollef" == Tollef Fog Heen  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

Re: Salsa as authentication provider for Debian

[Bernd Zeimetz]

Hi,


On 4/8/20 2:30 PM, Bastian Blank wrote:
n Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
>> 1. Can you still keep the "-guest" enforcement, so it's still easy to
>> recognize who is DD or not on salsa?
> 
> No.  The guest suffix was meant to avoid collisions with Debian
> accounts.  And the tool used to enforce it is unmaintained.
> 
> Also the only place that can for sure answer if someone is DD is
> nm.debian.org, not Salsa.

actually I see that as a big security risk. I the easiest case you'll
has a username that looks similar to one of a DD and that (malicious)
user is added to a project as the project admin thinks that use is a DD
and assumes that a DD can be trusted.

Having an easy way to identify DDs and non-DDs is a must imho.
Beeing able to keep your account and while getting rid of the -guest
when you become a DD would be an extra bonus.



Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Salsa as authentication provider for Debian

[Enrico Zini]

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 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Tollef Fog Heen]

]] 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

Re: Salsa as authentication provider for Debian

[Michael Lustfield]

On Thu, 9 Apr 2020 09:44:38 +0200
Enrico Zini  wrote:

> On Wed, Apr 08, 2020 at 03:48:43PM +, Luca Filipozzi wrote:
> 
> > > If you're instead generally expressing a fear that once we migrate to
> > > Salsa, we'll be in a local optimum that is going to be considered good
> > > enough to be worth bothering migrating to anything else, then I would
> > > argue that the problem wouldn't be having moved to Salsa as an OIDC
> > > provider, and rather that the next step that is proposed wouldn't be
> > > bringing enough compelling advantages to the problem at hand.  
> > 
> > Indeed, a local optimum is worrisome.  
> 
> If you mean that we should block a workable proposal for incremental
> improvement in case it turns out to be good enough, I think I don't want
> that.

I've already mentioned a couple points that are worrisome.

It also appears that there is an intent to drop -guest naming. I haven't seen
any technical discussion about this beyond learning about the current
structure. I am very concerned that this will have significant consequences in
regard to DSA-managed LDAP.

Perhaps the -guest naming should (definitely) be retired, but that sounds like a
very different can of worms that's better opened later.

> What we have /now/ is unsustainable, to the point that I'm afraid and
> ashamed of keeping some of the services I'm responsible for online.

As mentioned, we understand this. It is a very significant issue... one that
most were unaware of and some of us (hand raised) thought was already dealt
with. It's ... ugly, at best.

> [...]
> Then we can talk about a better, long-term, technically excellent,
> actively supported and sustainable solution, and by all means, I'd like
> to see that.

I do enjoy that there is consensus on the long-term goal.

> We could also do a post-mortem of why we have had what sounded like a
> good solution for more than one year and never managed to get it
> deployed. Not for pointing fingers: for avoiding getting in such a
> stalled situation in the future.
> 
> I am not at all in the mood for any of that, though, while I find myself
> starting responding to users' requests for help by apologising for the
> state things are.

(please forgive me if this sounds terse/blunt/rude... it's not intended)
I'm concerned that this sounds a lot like tunnel-vision, where only the fastest
and easiest way out of this cruddy situation is worth considering.

FWIW, that's very understandable, especially considering just how bad the status
quo has been for the past year or so. It's truly an ugly situation and one where
I can empathize with your pain. I can also understand the motivation to find the
nearest exit and I would probably be doing the exact same thing in your shoes.


For the moment, I would love to do whatever I can to help you with user issues.
I know this isn't a substitute for fixing the problem, but perhaps I can help
ease your burden and night terrors?


Meanwhile, there are now five people with an interest in doing what we can to
rectify the situation. It's unfortunate that we weren't aware of the stall a
year ago, but we're here now, and I don't intend to work slowly. I'm confident
you're aware of my "requirements gathering" phase. Design has been roughly
discussed and I'm now taking a day to bury myself in documentation. Since I'm
still playing the social distancing game, you can probably guess where my
weekend priorities will be. :)

Cheers,
-- 
Michael Lustfield

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 04:06:25PM +, Luca Filipozzi wrote:

> Another view point: I don't think that one's username should change as
> one's role(s) with the organization changes. If we could avoid that...

Agreed!


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 03:48:43PM +, Luca Filipozzi wrote:

> > If you're instead generally expressing a fear that once we migrate to
> > Salsa, we'll be in a local optimum that is going to be considered good
> > enough to be worth bothering migrating to anything else, then I would
> > argue that the problem wouldn't be having moved to Salsa as an OIDC
> > provider, and rather that the next step that is proposed wouldn't be
> > bringing enough compelling advantages to the problem at hand.
> 
> Indeed, a local optimum is worrisome.

If you mean that we should block a workable proposal for incremental
improvement in case it turns out to be good enough, I think I don't want
that.

What we have /now/ is unsustainable, to the point that I'm afraid and
ashamed of keeping some of the services I'm responsible for online.

We have come up a proposal that could be deployed in a couple of weeks
of off-working-hours straightforward work, with no need to deploy
any new infrastructural component. It can solve the urgent issues.

Then we can talk about a better, long-term, technically excellent,
actively supported and sustainable solution, and by all means, I'd like
to see that.

We could also do a post-mortem of why we have had what sounded like a
good solution for more than one year and never managed to get it
deployed. Not for pointing fingers: for avoiding getting in such a
stalled situation in the future.

I am not at all in the mood for any of that, though, while I find myself
starting responding to users' requests for help by apologising for the
state things are.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

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.izn7jdyufch7k...@enricozini.org


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Xavier]

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)

>> 
> 
> Very helpful response!

Thanks ;-)

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

Re: Salsa as authentication provider for Debian

[Steve McIntyre]

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.st...@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

Re: Salsa as authentication provider for Debian

[Tollef Fog Heen]

]] 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

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Wed, Apr 08, 2020 at 03:18:39PM +0200, Enrico Zini wrote:
> On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote:
> 
> > > I understand you want to recognize DDs from other contributors, but why?
> > > Does it help you with permissions, does it help understand who someone
> > > is, or is it a habit that has been there since Alioth?
> > 
> > For me, it's easier to trust a DD than a non-DD, so I'll grant a role
> > with higher permission if they request to join a team/project.
> 
> I think this has ups and downs.

Another view point: I don't think that one's username should change as
one's role(s) with the organization changes. If we could avoid that...

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

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

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Wed, Apr 08, 2020 at 05:28:37PM +0200, Enrico Zini wrote:
> On Wed, Apr 08, 2020 at 03:00:31PM +, Luca Filipozzi wrote:
> 
> > > Question: is there something in the proposed Salsa plan that somehow
> > > blocks experimenting with, introducing, or migrating to Keycloak in the
> > > future?
> > 
> > The further we go down one path, the harder, in my opinion, to change
> > later.
> 
> I think we're not really going "down one path": we're trying to dig
> ourselves "out of one pit".
> 
> I'll have to repeat the question: is there something specific in the
> proposed Salsa plan, that somehow blocks experimenting with,
> introducing, or migrating to Keycloak or some other solution in the
> future?

I think introduction of the broker is the compelling use case. I
appreciate that you may not view that as sufficient compelling.

Additionally, I'd prefer keeping SPs separate from IdPs, have them speak
to each other using standard protocols, etc. I don't view making Gitlab
an IdP as appropriate.

> From what I can see so far, we're starting a migration to OIDC, removing
> one of 3 user databases, adopting more standards, and doing some general
> cleanup along the way, which makes me think Salsa could be considered an
> iterative step towards a migration to anything else.

Very good outcomes, to be sure.

> If you're instead generally expressing a fear that once we migrate to
> Salsa, we'll be in a local optimum that is going to be considered good
> enough to be worth bothering migrating to anything else, then I would
> argue that the problem wouldn't be having moved to Salsa as an OIDC
> provider, and rather that the next step that is proposed wouldn't be
> bringing enough compelling advantages to the problem at hand.

Indeed, a local optimum is worrisome.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

reminder: I'm replying linearly (in this case, at the end of a chain of
email) and from what I know (keycloak, SAML and OIDC).

On Tue, Apr 07, 2020 at 04:08:37PM +0200, Xavier wrote:
> Le 07/04/2020 à 16:02, Enrico Zini a écrit :
> > On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote:
> > 
> >> With a SSO, I don't think it's a good thing to have a protected app as
> >> user database (even if it's possible). Then migration consists to
> >> extract gitlab accounts and push them in LDAP (2 branches, one for DD,
> >> one for guests)
> > 
> > Ok, please help me to see where that would be an issue.
> 
> It's not an issue. With a SSO we shall probably change this: salsa
> accounts will be created on-the-fly using federation mechanism, then
> there is only one user database (LDAP with 2 branches)

The Debian LDAP is atypical in a variety of ways, it's true.

Like LLNG, Keycloak use mappers to pull / transform as necessary.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

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.

> 

Very helpful response!

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 03:00:31PM +, Luca Filipozzi wrote:

> > Question: is there something in the proposed Salsa plan that somehow
> > blocks experimenting with, introducing, or migrating to Keycloak in the
> > future?
> 
> The further we go down one path, the harder, in my opinion, to change
> later.

I think we're not really going "down one path": we're trying to dig
ourselves "out of one pit".

I'll have to repeat the question: is there something specific in the
proposed Salsa plan, that somehow blocks experimenting with,
introducing, or migrating to Keycloak or some other solution in the
future?

From what I can see so far, we're starting a migration to OIDC, removing
one of 3 user databases, adopting more standards, and doing some general
cleanup along the way, which makes me think Salsa could be considered an
iterative step towards a migration to anything else.

If you're instead generally expressing a fear that once we migrate to
Salsa, we'll be in a local optimum that is going to be considered good
enough to be worth bothering migrating to anything else, then I would
argue that the problem wouldn't be having moved to Salsa as an OIDC
provider, and rather that the next step that is proposed wouldn't be
bringing enough compelling advantages to the problem at hand.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

reminder: I'm answering these linearly and i'm speaking from what I know
(keycloak) not what I don't (LLNG). I expect LLNG is generally similar.

On Tue, Apr 07, 2020 at 08:53:47AM +0200, Bastian Blank wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that are then promoted to full Debian identities (in
> > LDAP) if they complete the onboarding process.
> 
> You are proposing a different idea, however you are not yet proposing a
> project with actionable items on it.  If you think this is worthwhile,
> please provide at least the following things:

Responding to "here's an idea: try keycloak" with "publish a full plan"
creates a mountain when we're just at the foothills. I appreciate that,
from your perspective, you've been at this for a year and are
frustrated. I'll respond briefly to these below but, if we want a
fulsome plan, we should create a wiki page with the use cases and
evaluate things against the use cases a bit more.

> - Workflows, esp non-DD to DD and vice versa.

non-DDs can create accounts locally in keycloak and/or tie them to
social identity providers ("let them use existing credentials"). If they
becomee DDs, later, we add them to LDAP and cause them to 'merge' their
accounts on next login (or we use keycloak's API).

> - Self service, e.g. user signup, how do users add OIDC clients, how add

User signup is described above. Individual services could accept all
users or could require specific role assignment. Service owners would
then need to decide on role assignment mechanism.

I've not tried empowering non-admin users to add service providers
to a keycloak IdP. I don't doubt it's possible, just have to try.


>   groups/roles to OIDC info.

Yes, keycloak has powerful mapping capability to allow groups/roles to
be exposed as assertions to service providers.

> - Salsa, how should it work together.

Gitlab can use OIDC as an OmniAuth provider.

> - Additional features

> - Who is willing to maintain this long-term

I'm not committing DSA to this but I'm encouraged by their interest in a
demo.

There are at least three people on the thread who are familiary with
SAML/OIDC who are interested in supporting this service.

> - Exit strategy

I'm still at ideation.


> Anyway, I took a quick look into Keycloak.
> 
> What I find particular interesting is:
> - they use UUID for user identification

internally, yes. what is passed to a service provider as an identity
assertion can be configured through mapping rules on an SP-by-SP basis

> - users and groups can have arbitrary attributes attached to them,
>   however they are not self service
> - it is a complete authorization solution
> 
> What isn't so great
> - no particular good admin interface (there are 40+ settings for each
>   OIDC client alone)

Nearly all of those settings are auto-populated by exchanging metadata.
In SAML, the SP and the IdP exchange XML documents containing the
metadata. Tedious but works.  In OIDC, the SPI and the IdP point to each
other's 'well-known' configuration URLs to pull in the metadata. The
OIDC folks learned from SAML.

> - it can have forms without a required field, which can't be saved at
>   all.

Not sure what you're describing, here.

> - jboss.  Who considers itself capable of running public jboss
>   applications safely and securely?

Yes, there's a general lack of interest in Java and JBoss in our
community.

> Showstopper
> - no self service for group or even OIDC clients

More investigation required, frankly.

> - no U2F (okay, GitLab also still needs to make the step to webauthn)

> - requires Java 8, which is not supported on Debian Buster

This isn't true. I'm running keycloak in a demo for work using 
openjdk-11-jre-headless. Their documentation would do well to say Java 8 or 
later.

> I was not able to see the killer feature of this setup or at least one
> feature that we must have.

I think the 'killer feature' is independent of Keycloak. It's the
introduction of an identity broker that offers a single place for
service providers to integrate, offers social-to-identity for users,
etc.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

I'm working through the responses linearly, so...

On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote:
> On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote:
> 
> > > I don't know keycloak: what are the maintenance costs, and what would be
> > > the benefits over time?
> > > 
> > > Right now, with the proposal waldi just posted, we have very little to
> > > no added maintenance cost, possibly negative maintenance cost once we
> > > take sso.debian.org and the current handcrafted salsa subscription thing
> > > offline. The amount of code deployed compared to the status quo would go
> > > *down*. The user interface and user experience for the lot would be good
> > > and well known. Gitlab's codebase, while large and complex, is widely
> > > deployed, and we already have know-how about it in Debian.

Having read the response relating to an audit of gitlab source code, I
would question whether gitlab is 'saft'. That said, we'd want similar
attestations for LLNG or keycloak. Keycloak has been selected by a
number of governments / unis / etc. That's not to say that they did code
reviews; it is to say that it is receiving some adoption (which I think
will grow).

I know more about keycloak than LLNG, so I'll restrict my responses to
Keycloak, SAML and OIDC (OpenID Connect).

> > Having just joined this conversation, the above is an argument that is
> > difficult to refute: one can always argue that 'one in the hand is
> > better than one in the bush'.
> 
> Yes :/  I think that's more or less where we are now, unfortunately,
> after a year or more failing to find people to deploy and maintain
> alternatives.

I think people are stepping forward, albeit slowly.

> On one hand, client certificate handling in browsers gets worse over
> time, and the current sso solution is effectively running on people
> collecting all sorts of workaround instructions in the excellent wiki
> page at https://wiki.debian.org/DebianSingleSignOn

I suggest that we move from client certificate-based authentication to
SAML- or OIDC-based authentication.

> On the other hand, signing in for non-DDs is a major hurdle that takes
> literally weeks, when one can find out how to do it at all. We DDs care
> little about that, it's Not Our Problem. That barrier makes joining
> nm.debian.org to become a DD a challenge in itself. Other things like
> managing one's own information on contributors.debian.org are just not
> worth the challenge, and I'm planning to take contributors.d.o offline
> soon, because I/we can't, ethically and legally, publish people's
> information without giving those people a reasonable chance to control
> it.

With keycloak, we could:
* allow people to create accounts locally in keycloak, and//or
* allow people to create accounts tied to other identity providers
 (Gmail, etc.)
 
 This is the 'social-to-identity' concept where an organization wishes
 to make onboarding of new users as friendly as possible (let them use
 their existing credentials). If, later, they become a customer (i.e.,
 Debian Developer), then you promote their account from 'social' to
 'internal').

> > My DSA colleagues asked for demo and I'm building that up, currently. I
> > view this as a positive but not definitive step in the maintenance
> > questions.
> > 
> > I appreciate that the idea of using keycloak as an IdB requires everyone
> > to shift perspective.
> > 
> > Let me know if you have appetite (or not*) to discuss the above.
> 
> Personally I'm interested in anything that works and that I can have a
> very good confidence that somebody will maintain over time.
> 
> I care about maintenance and sustainability more than about anything
> else, because I'm the one who's been forced to set up and maintain SSO
> in Debian mostly alone for 8 years, because everybody else walked away
> from it and I could not.
> 
> OIDC supports various authentication sources, and the Salsa plan
> decouples OIDC from LDAP allowing them to evolve independently, removes
> custom nonstandard components, and includes the option of migrating away
> to something else in the future. In my understanding it enables
> experimentation with other systems rather than blocking it.
> 
> Question: is there something in the proposed Salsa plan that somehow
> blocks experimenting with, introducing, or migrating to Keycloak in the
> future?

The further we go down one path, the harder, in my opinion, to change
later.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 10:05:19AM -0400, Sam Hartman wrote:

> I don't think it blocks your proposal, but I do think that having
> something to audit repos and make sure only current dds have access to
> certain repos is a valuable user no]eed.
> And I think the current-status-permission check need is also valid and
> probably more critical.

Sure. I seriously think we don't have enough audit tools in Debian, and
I'm strongly in favour of having more.

With regards of current-status-permission, I checked with waldi, and
with some extra work it is possible to add some visible information to
the user's page, synced from nm.debian.org, about their official
membership status: we can totally have that.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Enrico" == Enrico Zini  writes:


Enrico> I agree that with the current proposal, the use case of
Enrico> "grant a person permission based on their status, which is
Enrico> somehow revoked or blocked if the status goes away" becomes
Enrico> something we might not be able to do.

Fair enough.  But there is the use case of sanity check that foo is a dd
before granting them permissions today because I'm going to think about
it a lot more if they aren't a dd  is a valid use case.

Also, I do think there are some repos that we really only want a dd
writing to.  As an example, keyring-maint.  Now if something goes bad
for keyring maint we're going to notice it, and keyring maint would
certainly be in the loop if someone from keyring-maint retired.

I don't think it blocks your proposal, but I do think that having
something to audit repos and make sure only current dds have access to
certain repos is a valuable user no]eed.
And I think the current-status-permission check need is also valid and
probably more critical.

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote:

> > I understand you want to recognize DDs from other contributors, but why?
> > Does it help you with permissions, does it help understand who someone
> > is, or is it a habit that has been there since Alioth?
> 
> For me, it's easier to trust a DD than a non-DD, so I'll grant a role
> with higher permission if they request to join a team/project.

I think this has ups and downs.

Currently, if someone doesn't have -guest on Salsa, they are either
active DDs or locked accounts. The moment a non-"-guest" person loses
their DD status, their account gets locked.

This is currently causing trouble: when one loses DD status, suddenly
they lose access to all their repositories until they get readded to
everything with a new -guest account. For repositories that only they
controlled, this requires admin intervention and headaches.

This has happened, and it's serious enough to make Salsa not suitable
for hosting long-term projects at the moment: I don't want to build my
projects' ecosystem on something which locks me out the moment I decide
to go emeritus, or the moment I get my Debian membership temporarily
suspended for whatever reason.

I would argue that it would make more sense to grant roles and
permissions to people based on their past contributions and reputation,
rather than based on current status.

I agree that with the current proposal, the use case of "grant a person
permission based on their status, which is somehow revoked or blocked if
the status goes away" becomes something we might not be able to do.

In my opinion this change, rather than opening a new problem, fixes an
old, nasty one instead.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Enrico" == Enrico Zini  writes:

Enrico> On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote:
>> Sigh, but it makes sense too. Will nm.d.o have a field which
>> reflects the username on salsa?

Enrico> It finally will, yes! \o/

Enrico> It's been quite painful not having that mapping so far.


Enrico, in addition to your ack/nack collecting, I think it is valuable
to collect unmet needs to guide future work.

It sounds like multiple people are saying there's a need to easily
determine whether at the current time a given username is a dd.

In practice removing the -guest thing will make that harder for the
common case.
I don't know that means it is a blocker, but it does sound like it means
that's an area where working to understand and meet that user need
independently of your proposal would be good.

(And if it is a blocker, obviously it becomes a higher priority.)

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote:

> Sigh, but it makes sense too. Will nm.d.o have a field which reflects
> the username on salsa?

It finally will, yes! \o/

It's been quite painful not having that mapping so far.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 08:04:59PM +0800, Shengjing Zhu wrote:

> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
> 
> The reason why I ask for this is because
> 1. If a -guest account is added to a project in salsa Debian group,
> the group name is also shown on the personal profile.
> 2. Users can make their profile private, so you don't know what group
> they belong to.
> 3. To search in the Debian group member page takes too many steps.
> 
> If there's an easy way I'm not aware of, then I'm fine with it.

I checked with waldi, and with some extra work it is possible to add
some visible information to the user's page, synced from nm.debian.org,
about their official membership status.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Shengjing Zhu]

On Wed, Apr 8, 2020 at 8:33 PM Bastian Blank  wrote:
>
> Hi Zhu
>
> On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> No.  The guest suffix was meant to avoid collisions with Debian
> accounts.  And the tool used to enforce it is unmaintained.
>
> Also the only place that can for sure answer if someone is DD is
> nm.debian.org, not Salsa.
>

Sigh, but it makes sense too. Will nm.d.o have a field which reflects
the username on salsa?
Although it takes multi steps to figure out the user status when you
click a "Request to join" link sent by salsa.

--
Shengjing Zhu

Re: Salsa as authentication provider for Debian

[Ole Streicher]

Ulrike Uhlig  writes:
> On 08.04.20 13:50, Shengjing Zhu wrote:
>> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank  wrote:
>
>> 1. Can you still keep the "-guest" enforcement, so it's still easy to
>> recognize who is DD or not on salsa?
>
> Could you explain a bit better why you think that this is needed?
>
> I understand you want to recognize DDs from other contributors, but why?
> Does it help you with permissions, does it help understand who someone
> is, or is it a habit that has been there since Alioth?

I don't know the exact proposed rules here, but I could imagine that
without these rules anyone cann fill the namespace of nice Debian user
names. And there is the danger that someone hijacks the user name of a
Debian user who is still not on Salsa. Or an emeritus name or so.

I would also like to have a visible distinction between "trusted" names
(where the owner is verified via key) and random names, in one way or
the other.

Cheers

Ole

Re: Salsa as authentication provider for Debian

[Bastian Blank]

Hi Zhu

On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

No.  The guest suffix was meant to avoid collisions with Debian
accounts.  And the tool used to enforce it is unmaintained.

Also the only place that can for sure answer if someone is DD is
nm.debian.org, not Salsa.

> 2. For transition between non-DD and DD, could salsa admin rename the
> username by requests?

No.

Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

Re: Salsa as authentication provider for Debian

[Shengjing Zhu]

On Wed, Apr 8, 2020 at 8:13 PM Ulrike Uhlig  wrote:
>
> Hi!
>
> On 08.04.20 13:50, Shengjing Zhu wrote:
> > On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank  wrote:
>
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> Could you explain a bit better why you think that this is needed?
>
> I understand you want to recognize DDs from other contributors, but why?
> Does it help you with permissions, does it help understand who someone
> is, or is it a habit that has been there since Alioth?

For me, it's easier to trust a DD than a non-DD, so I'll grant a role
with higher permission if they request to join a team/project.

-- 
Shengjing Zhu

Re: Salsa as authentication provider for Debian

[Ulrike Uhlig]

Hi!

On 08.04.20 13:50, Shengjing Zhu wrote:
> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank  wrote:

> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

Could you explain a bit better why you think that this is needed?

I understand you want to recognize DDs from other contributors, but why?
Does it help you with permissions, does it help understand who someone
is, or is it a habit that has been there since Alioth?

ulrike

Re: Salsa as authentication provider for Debian

[Shengjing Zhu]

On Wed, Apr 8, 2020 at 7:50 PM Shengjing Zhu  wrote:
[...]
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

The reason why I ask for this is because
1. If a -guest account is added to a project in salsa Debian group,
the group name is also shown on the personal profile.
2. Users can make their profile private, so you don't know what group
they belong to.
3. To search in the Debian group member page takes too many steps.

If there's an easy way I'm not aware of, then I'm fine with it.

-- 
Shengjing Zhu

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:

> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

I'll leave answering these questions to Waldi / Salsa admins.

I would like to stick to investing energy in solving problems that we
really have, though, so I'm curious: do you have specific reasons in
mind for asking to preserve the "-guest" enforcement on Salsa?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Shengjing Zhu]

On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank  wrote:
[...]
> ## Highlevel plan
>
> - 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.
> - Salsa allows user renames and drops namespace rules for users (i.e., no more
>   requirement for -guest suffix).
> - 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.
>
> ## Fixed problems
>
> - We get a user source everyone can use both as service provider and user.
> - Users can rename themselves before becoming DDs, and retain all information
>   both on Salsa and on other services. This also works while transitioning
>   between non-DD and DD, and back.
>

1. Can you still keep the "-guest" enforcement, so it's still easy to
recognize who is DD or not on salsa?
2. For transition between non-DD and DD, could salsa admin rename the
username by requests?

For 1, I think it doesn't make the original plan more complicated.
For 2, I think it doesn't either, as you already plan to support renaming.

-- 
Shengjing Zhu

Re: Salsa as authentication provider for Debian

[Sam Hartman]

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



signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Wed, Apr 08, 2020 at 04:51:49AM +, 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 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Paul Wise]

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

Re: Salsa as authentication provider for Debian

[Bastian Blank]

Hi Paul

On Tue, Apr 07, 2020 at 03:20:52PM +, 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

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Tue, Apr 07, 2020 at 03:20:52PM +, 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 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Xavier" == Xavier   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

Re: Salsa as authentication provider for Debian

[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?

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?

Re: Salsa as authentication provider for Debian

[Paul Wise]

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

Re: Salsa as authentication provider for Debian

[Enrico Zini]

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 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Michael Lustfield]

On Tue, 7 Apr 2020 13:50:06 +0200
Enrico Zini  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

Re: Salsa as authentication provider for Debian

[Xavier]

Le 07/04/2020 à 16:02, Enrico Zini a écrit :
> On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote:
> 
>> With a SSO, I don't think it's a good thing to have a protected app as
>> user database (even if it's possible). Then migration consists to
>> extract gitlab accounts and push them in LDAP (2 branches, one for DD,
>> one for guests)
> 
> Ok, please help me to see where that would be an issue.

It's not an issue. With a SSO we shall probably change this: salsa
accounts will be created on-the-fly using federation mechanism, then
there is only one user database (LDAP with 2 branches)

> The current status of accounts, is that:
> 
>  - There is only one LDAP server, DSA-managed, on db.debian.org, which
>has accounts that do not end in "-guest". They may be DD or ex-DD
>accounts, or "guest accounts" created for non-DDs who need to have
>temporary access to porterboxes
> 
>  - There are accounts ending in "-guest" (that are not "guest
>accounts"), that are not managed by DSA, and used to be on Alioth's
>separate LDAP when alioth existed.
>
>  - "-guest" accounts for purposes on sso.debian.org authentication are
>now stored on a hand-maintained text file that is exported somehow to
>serve as an apache authentication source for sso.debian.org
> 
>  - "-guest" accounts on Salsa are stored on Salsa's user database
> 
> We currently have all sorts of overlaps and corner cases:
> 
>  - "guest accounts" in LDAP that do not end in "-guest" and are for
>non-DDs
>  - "-guest" accounts in Salsa for DDs and ex-DDs, with the part before
>"-guest" not matching the LDAP account name.
> 
> I wonder if we have the same "-guest" accounts in Salsa and in the
> sso.debian.org text file, that are controlled by different people?
> 
> With the Salsa proposal:
> 
>  - the text file disappears, reducing the count of user databases from 3
>to 2
>  - LDAP remains as it is, and Salsa remains as it is
>  - DD accounts remain on LDAP
>  - We gain an explicit mapping between LDAP accounts and Salsa accounts,
>via nm.debian.org, that we currently do not have
>  - People who gain or lose DD status can keep using their Salsa account
>without needing to migrate from "something-guest" to "something", or
>from "something" to "something-guest"
> 
> With the Salsa proposal the only change from here that I can see is that
> we would start to have non-DD accounts on Salsa that do not end with
> "-guest", like we already have non-DD accounts on LDAP now that do not
> end with "-guest".
> 
> I still don't see how the Salsa proposal makes adoption of a new system
> harder than what we have now: removing one user database and introducing
> a mapping between the remaining two, seem to me to make further
> adoptions actually easier.

No not harder, just different ;-)

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote:

> With a SSO, I don't think it's a good thing to have a protected app as
> user database (even if it's possible). Then migration consists to
> extract gitlab accounts and push them in LDAP (2 branches, one for DD,
> one for guests)

Ok, please help me to see where that would be an issue.

The current status of accounts, is that:

 - There is only one LDAP server, DSA-managed, on db.debian.org, which
   has accounts that do not end in "-guest". They may be DD or ex-DD
   accounts, or "guest accounts" created for non-DDs who need to have
   temporary access to porterboxes

 - There are accounts ending in "-guest" (that are not "guest
   accounts"), that are not managed by DSA, and used to be on Alioth's
   separate LDAP when alioth existed.
   
 - "-guest" accounts for purposes on sso.debian.org authentication are
   now stored on a hand-maintained text file that is exported somehow to
   serve as an apache authentication source for sso.debian.org

 - "-guest" accounts on Salsa are stored on Salsa's user database

We currently have all sorts of overlaps and corner cases:

 - "guest accounts" in LDAP that do not end in "-guest" and are for
   non-DDs
 - "-guest" accounts in Salsa for DDs and ex-DDs, with the part before
   "-guest" not matching the LDAP account name.

I wonder if we have the same "-guest" accounts in Salsa and in the
sso.debian.org text file, that are controlled by different people?

With the Salsa proposal:

 - the text file disappears, reducing the count of user databases from 3
   to 2
 - LDAP remains as it is, and Salsa remains as it is
 - DD accounts remain on LDAP
 - We gain an explicit mapping between LDAP accounts and Salsa accounts,
   via nm.debian.org, that we currently do not have
 - People who gain or lose DD status can keep using their Salsa account
   without needing to migrate from "something-guest" to "something", or
   from "something" to "something-guest"

With the Salsa proposal the only change from here that I can see is that
we would start to have non-DD accounts on Salsa that do not end with
"-guest", like we already have non-DD accounts on LDAP now that do not
end with "-guest".

I still don't see how the Salsa proposal makes adoption of a new system
harder than what we have now: removing one user database and introducing
a mapping between the remaining two, seem to me to make further
adoptions actually easier.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Xavier]

Le 07/04/2020 à 14:38, Enrico Zini a écrit :
> On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote:
> 
>>> 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?
>>
>> No, just to migrate accounts
> 
> Could you give some more detail of what you mean?

With a SSO, I don't think it's a good thing to have a protected app as
user database (even if it's possible). Then migration consists to
extract gitlab accounts and push them in LDAP (2 branches, one for DD,
one for guests)

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote:

> > 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?
> 
> No, just to migrate accounts

Could you give some more detail of what you mean?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Xavier]

Le 07/04/2020 à 13:50, Enrico Zini a écrit :
> On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
> 
>> Resume of proposition:
>>  * all users managed by SSO; self-registration authorized with "-guest"
>>in a distinct LDAP branch
>>  * GitLab becomes a slave of SSO using SAML (or OIDC)
>>  * other applications are protected by handlers/GateKeepers. If LLNG is
>>chosen, just to add few lines in Nginx configuration
>>  * new applications can be protected using handlers, SAML, CAS, OIDC,...
>>
>> 
> 
> I greatly appreciate yours and Luca's and Michael's proposals, and
> offers of help.

Thanks !

> 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'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?

No, just to migrate accounts

> If not, then we could start with that, which requires no deployment of
> new software, and on which we can make progress immediately, and buy
> time for everyone to work out the perfect solution, meanwhile moving on
> from an unsustainable status quo.
> 
> 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.
> 
> Enrico

Little addon: LLNG has a GPG auth plugin, this can be useful to
self-reinitialize lost passwords or unlock accounts if password policy
blocks it and/or register new DDs

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:

> Resume of proposition:
>  * all users managed by SSO; self-registration authorized with "-guest"
>in a distinct LDAP branch
>  * GitLab becomes a slave of SSO using SAML (or OIDC)
>  * other applications are protected by handlers/GateKeepers. If LLNG is
>chosen, just to add few lines in Nginx configuration
>  * new applications can be protected using handlers, SAML, CAS, OIDC,...
> 
> 

I greatly appreciate yours and Luca's and Michael's proposals, and
offers of help.

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'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?

If not, then we could start with that, which requires no deployment of
new software, and on which we can make progress immediately, and buy
time for everyone to work out the perfect solution, meanwhile moving on
from an unsustainable status quo.

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.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Xavier]

Le 05/04/2020 à 20:46, Bastian Blank a écrit :
> Dear Debian fellows
> 
> Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the
> following plan.  At the same time we declare the following services as EOL:
> - sso.debian.org and
> - parts of the Salsa self service interface.
> 
> We asked DPL, NM, DSA and the Salsa admins already for feedback about what we
> intend to do.
> 
> We mostly got positive feedback from them, with some reservations about the
> user renames.
> 
> We did not receive a response from DSA to date.  We only got some personal
> remarks from jcristau and weasel on IRC.  They don't want to handle Salsa
> differently and store information.  Also they declared worry about user name
> conflicts.
> 
> We did some changes to remedy those, so we scrapped the changes we had asked
> DSA to do and will check for name conflicts in nm.debian.org before sending
> user creation requests to DSA.
> 
> Regards,
> Enrico and Bastian

Hi,

I can help if you want to use lemondap-ng (LLNG:
https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng)

> ## Current state
> 
> - We have multiple user sources:
>   - Debian LDAP,
>   - Salsa (which syncs DD from Debian LDAP) and
>   - "Alioth" guest "LDAP" for sso.debian.org.

LLNG can handle multiple sources (2 modules for that: user choice or
automatic calculation using combination module)

> - We have no way to rename users, neither within the Debian LDAP, nor Salsa.
>   Renames require a complete new user.
> - A person transitioning between non-DD and DD needs a new user and loses all
>   state.
> - Guest users on Salsa are forced to end with `-guest`.
> 
> ## Highlevel plan
> 
> - 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.

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.

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

> - Salsa allows user renames and drops namespace rules for users (i.e., no more
>   requirement for -guest suffix).



> - 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.
> 
> ## Fixed problems
> 
> - We get a user source everyone can use both as service provider and user.
> - Users can rename themselves before becoming DDs, and retain all information
>   both on Salsa and on other services. This also works while transitioning
>   between non-DD and DD, and back.
> 
> ## Corner cases
> 
> The Salsa and LDAP databases don't need to be in sync:
> 
> - The interaction between the two namespaces only happens when the Salsa
>   namespace provides the value for a new DD's LDAP UID. By using salsa as
>   default for LDAP UID, we keep the names roughly in sync for convenience
> - Conflicts can happen when a prospective new DD has a Salsa username that
>   corresponds to an already allocated LDAP uid, and they can be detected and
>   handled on nm.debian.org before account creation: people can be told that
>   their salsa username is already in use in LDAP, and get a chance to rename 
> it.
> - If one renames their Salsa account after becoming DD, someone else could
>   start using the old name and exploit the confusion. This would be a rare
>   occurrence, and Salsa admins can lock the malicious account if that happens.
> 
> People can rename their account on Salsa even after the account exists in 
> LDAP,
> since the OIDC identifying information would be the subject, which is the
> GitLab internal user ID, which is preserved across renames.
> 
> nm.debian.org will provide official membership information to Salsa, so the
> Debian group on Salsa will remain, showing DD status.
> 
> ## Required changes
> 
> ### Salsa
> 
> - Enable sign-on and allow user rename (last step).
> - Remove user support from Salsa self service interface.
> 
> ### Salsa user sync
> 
> - Use nm.debian.org as data source for official DD status.
> - Add/remove @debian.org e-mail addresses in user information, from
>   nm.debian.org
> 
> ### nm.debian.org
> 
> - Support OIDC to get subject, username, display name and e-mail address for
>   users.
> - Supply information about DD for consumption by Salsa user sync.
> - Check for username conflicts.
> 
> ### sso.debian.org
> 
> - Authenticate via OIDC to provide certificate management for a transition
>   period, until all sso-using services have migrated to OIDC
> 
> ## Exit plan
> 
> Should GitLab and/or Salsa become unmaintainable, what do we need to migrate
> away?

It's easy to 

Re: Salsa as authentication provider for Debian

[Geert Stappers]

On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote:
> On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote:
> 
> > > I don't know keycloak: what are the maintenance costs, and what would be
> > > the benefits over time?
> > > 
> > > Right now, with the proposal waldi just posted, we have very little to
> > > no added maintenance cost, possibly negative maintenance cost once we
> > > take sso.debian.org and the current handcrafted salsa subscription thing
> > > offline. The amount of code deployed compared to the status quo would go
> > > *down*. The user interface and user experience for the lot would be good
> > > and well known. Gitlab's codebase, while large and complex, is widely
> > > deployed, and we already have know-how about it in Debian.
> > 
> > Having just joined this conversation, the above is an argument that is
> > difficult to refute: one can always argue that 'one in the hand is
> > better than one in the bush'.
> 
> Yes :/  I think that's more or less where we are now, unfortunately,
> after a year or more failing to find people to deploy and maintain
> alternatives.
> 
> On one hand, client certificate handling in browsers gets worse over
> time, and the current sso solution is effectively running on people
> collecting all sorts of workaround instructions in the excellent wiki
> page at https://wiki.debian.org/DebianSingleSignOn
> 
> On the other hand, signing in for non-DDs is a major hurdle that takes
> literally weeks, when one can find out how to do it at all. We DDs care
> little about that, it's Not Our Problem. That barrier makes joining
> nm.debian.org to become a DD a challenge in itself. Other things like
> managing one's own information on contributors.debian.org are just not
> worth the challenge, and I'm planning to take contributors.d.o offline
> soon, because I/we can't, ethically and legally, publish people's
> information without giving those people a reasonable chance to control
> it.
> 
> 
> > My DSA colleagues asked for demo and I'm building that up, currently. I
> > view this as a positive but not definitive step in the maintenance
> > questions.
> > 
> > I appreciate that the idea of using keycloak as an IdB requires everyone
> > to shift perspective.
> > 
> > Let me know if you have appetite (or not*) to discuss the above.
> 
> Personally I'm interested in anything that works and that I can have a
> very good confidence that somebody will maintain over time.
> 
> I care about maintenance and sustainability more than about anything
> else, because I'm the one who's been forced to set up and maintain SSO
> in Debian mostly alone for 8 years, because everybody else walked away
> from it and I could not.
> 
> OIDC supports various authentication sources, and the Salsa plan
> decouples OIDC from LDAP allowing them to evolve independently, removes
> custom nonstandard components, and includes the option of migrating away
> to something else in the future. In my understanding it enables
> experimentation with other systems rather than blocking it.
> 
> Question: is there something in the proposed Salsa plan that somehow
> blocks experimenting with, introducing, or migrating to Keycloak in the
> future?

Euh there is
| What does keycloak provide over something like lemonldap or similar tools? 
elsewhere in this thread.  So I take the liberty to change one question

 It there something in the proposed Salsa plan
 that somehow blocks experimenting with, introducing, or migrating
 to an identity provider in the future?



Regards
Geert Stappers
-- 
Silence is hard to parse

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote:

> > I don't know keycloak: what are the maintenance costs, and what would be
> > the benefits over time?
> > 
> > Right now, with the proposal waldi just posted, we have very little to
> > no added maintenance cost, possibly negative maintenance cost once we
> > take sso.debian.org and the current handcrafted salsa subscription thing
> > offline. The amount of code deployed compared to the status quo would go
> > *down*. The user interface and user experience for the lot would be good
> > and well known. Gitlab's codebase, while large and complex, is widely
> > deployed, and we already have know-how about it in Debian.
> 
> Having just joined this conversation, the above is an argument that is
> difficult to refute: one can always argue that 'one in the hand is
> better than one in the bush'.

Yes :/  I think that's more or less where we are now, unfortunately,
after a year or more failing to find people to deploy and maintain
alternatives.

On one hand, client certificate handling in browsers gets worse over
time, and the current sso solution is effectively running on people
collecting all sorts of workaround instructions in the excellent wiki
page at https://wiki.debian.org/DebianSingleSignOn

On the other hand, signing in for non-DDs is a major hurdle that takes
literally weeks, when one can find out how to do it at all. We DDs care
little about that, it's Not Our Problem. That barrier makes joining
nm.debian.org to become a DD a challenge in itself. Other things like
managing one's own information on contributors.debian.org are just not
worth the challenge, and I'm planning to take contributors.d.o offline
soon, because I/we can't, ethically and legally, publish people's
information without giving those people a reasonable chance to control
it.


> My DSA colleagues asked for demo and I'm building that up, currently. I
> view this as a positive but not definitive step in the maintenance
> questions.
> 
> I appreciate that the idea of using keycloak as an IdB requires everyone
> to shift perspective.
> 
> Let me know if you have appetite (or not*) to discuss the above.

Personally I'm interested in anything that works and that I can have a
very good confidence that somebody will maintain over time.

I care about maintenance and sustainability more than about anything
else, because I'm the one who's been forced to set up and maintain SSO
in Debian mostly alone for 8 years, because everybody else walked away
from it and I could not.

OIDC supports various authentication sources, and the Salsa plan
decouples OIDC from LDAP allowing them to evolve independently, removes
custom nonstandard components, and includes the option of migrating away
to something else in the future. In my understanding it enables
experimentation with other systems rather than blocking it.

Question: is there something in the proposed Salsa plan that somehow
blocks experimenting with, introducing, or migrating to Keycloak in the
future?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Bastian Blank]

Hi Luca

On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> That said, please consider an approach that would see keycloak used as
> an idenitity broker, allowing external users to create accounts using
> social identities that are then promoted to full Debian identities (in
> LDAP) if they complete the onboarding process.

You are proposing a different idea, however you are not yet proposing a
project with actionable items on it.  If you think this is worthwhile,
please provide at least the following things:

- Workflows, esp non-DD to DD and vice versa.
- Self service, e.g. user signup, how do users add OIDC clients, how add
  groups/roles to OIDC info.
- Salsa, how should it work together.
- Additional features
- Who is willing to maintain this long-term
- Exit strategy

Anyway, I took a quick look into Keycloak.

What I find particular interesting is:
- they use UUID for user identification
- users and groups can have arbitrary attributes attached to them,
  however they are not self service
- it is a complete authorization solution

What isn't so great
- no particular good admin interface (there are 40+ settings for each
  OIDC client alone)
- it can have forms without a required field, which can't be saved at
  all.
- jboss.  Who considers itself capable of running public jboss
  applications safely and securely?

Showstopper
- no self service for group or even OIDC clients
- no U2F (okay, GitLab also still needs to make the step to webauthn)
- requires Java 8, which is not supported on Debian Buster

I was not able to see the killer feature of this setup or at least one
feature that we must have.

>Could be used as
> replacement for debsso, could be used for wiki, could be used for
> debconf, could be used for salsa.

But this is not different to what we already proposed.  Also all the
other modifications we need to do to for example Salsa and NM are
already the same.

Regards,
Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Re: Salsa as authentication provider for Debian

[Michael Lustfield]

On Mon, 6 Apr 2020 20:38:59 +0200
Enrico Zini  wrote:

> On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> 
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that are then promoted to full Debian identities (in
> > LDAP) if they complete the onboarding process. Could be used as
> > replacement for debsso, could be used for wiki, could be used for
> > debconf, could be used for salsa.  

What does keycloak provide over something like lemonldap or similar tools?

> [...]
> and well known. Gitlab's codebase, while large and complex, is widely
> deployed, and we already have know-how about it in Debian.

I was previously involved with a company that audited various git-hosting
services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so
please forgive the lack of specifics. Gitlab is a tool that gets many things
right, and many things wrong. Access control is an area where I have seen some
critical bugs. Some of those bugs lead me to not trust it as a non-internal
authentication source.

Security aside, and perhaps more importantly, is the vendor lock-in problem
that can be seen with Alioth. If that system were not being used as an
authentication source, then the whole migration would have been entirely
agnostic to such concerns and changing auth sources would never have come up.

Choosing to migrate to gitlab as an authentication source just introduces a
painful(?) migration for the sake of another similar migration in the future.

> I would not want to see a workable proposal that we could implement over
> the next two weeks and that we have the resources to maintain long-term,
> blocked by something that risks getting us stuck with sso.d.o for
> another bunch of years until we get it right, and possibly ending up
> being maintained long term by a team with a dwindling bandwidth and bus
> factor.

I was previously (before gitlab's deployment) lead to believe that the problem
was already being dealt with. Since this is still a problem, then I volunteer to
implement and maintain whatever solution is most appropriate.

Is there any summary of where those previous discussions lead and/or their
conclusions? I saw something about GSoC mentioned. Is there anything viable
which can be taken from that effort?

Also, please, don't focus on time to deployment. I'll do whatever we need in
order to implement a proper long-term solution. As you may have noticed- I take
my time to plan projects before execution. If anything, this is a change that
should involve more planning than anything else.

-- 
Michael Lustfield

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Mon, Apr 06, 2020 at 08:38:59PM +0200, Enrico Zini wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> 
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that are then promoted to full Debian identities (in
> > LDAP) if they complete the onboarding process. Could be used as
> > replacement for debsso, could be used for wiki, could be used for
> > debconf, could be used for salsa.
> 
> I don't know keycloak: what are the maintenance costs, and what would be
> the benefits over time?
> 
> Right now, with the proposal waldi just posted, we have very little to
> no added maintenance cost, possibly negative maintenance cost once we
> take sso.debian.org and the current handcrafted salsa subscription thing
> offline. The amount of code deployed compared to the status quo would go
> *down*. The user interface and user experience for the lot would be good
> and well known. Gitlab's codebase, while large and complex, is widely
> deployed, and we already have know-how about it in Debian.

Having just joined this conversation, the above is an argument that is
difficult to refute: one can always argue that 'one in the hand is
better than one in the bush'.

> I would not want to see a workable proposal that we could implement over
> the next two weeks and that we have the resources to maintain long-term,
> blocked by something that risks getting us stuck with sso.d.o for
> another bunch of years until we get it right, and possibly ending up
> being maintained long term by a team with a dwindling bandwidth and bus
> factor.

Again, I'm just joining this conversation now.

Keycloak is a RedHat-sponsored Java-based open-source project that
provides a standards-based (SAML and OpenID) Identity Provider (IdP). It
can also operate as an Identity Brokder (IdB).

As an IdP, it can use an internal data store for users (database) or an
external one (LDAP). It has a variety of workflows for user onboarding,
user managed access, etc.

As an IdB, it can be configured to allow 'social-to-identity' workflows
so that users may begin their identity experience using their existing
social identies (Gmail, Twitter, etc.). This is in addition to the users
from the above IdP for Debian Developers.

Service operators (websites, etc.) could then elect to accept all users
or to require a role assignment / group membership to grant access to
the service.

Finally, should a user have started with a social identity but have
successfully completed the Applicant process, then there are workflows
that would allow users to merge their identities.

My DSA colleagues asked for demo and I'm building that up, currently. I
view this as a positive but not definitive step in the maintenance
questions.

I appreciate that the idea of using keycloak as an IdB requires everyone
to shift perspective.

Let me know if you have appetite (or not*) to discuss the above.

Thanks,

Luca

* If not, then I'll stop advocating for this approach. There's the
  potential for a heated conversation, here, and I'm not up for that.

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Holger Levsen]

Dear waldi, Enrico,

On Sun, Apr 05, 2020 at 08:46:10PM +0200, Bastian Blank wrote:
[many many details]

yay! many thanks for starting & doing this, this is gonna be awesome!

( & thanks to those helping making this happen as well! Either by action or
thoughts.)

> ## Exit plan

I especially like that you have this in mind already.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:

> That said, please consider an approach that would see keycloak used as
> an idenitity broker, allowing external users to create accounts using
> social identities that are then promoted to full Debian identities (in
> LDAP) if they complete the onboarding process. Could be used as
> replacement for debsso, could be used for wiki, could be used for
> debconf, could be used for salsa.

I don't know keycloak: what are the maintenance costs, and what would be
the benefits over time?

Right now, with the proposal waldi just posted, we have very little to
no added maintenance cost, possibly negative maintenance cost once we
take sso.debian.org and the current handcrafted salsa subscription thing
offline. The amount of code deployed compared to the status quo would go
*down*. The user interface and user experience for the lot would be good
and well known. Gitlab's codebase, while large and complex, is widely
deployed, and we already have know-how about it in Debian.

I would not want to see a workable proposal that we could implement over
the next two weeks and that we have the resources to maintain long-term,
blocked by something that risks getting us stuck with sso.d.o for
another bunch of years until we get it right, and possibly ending up
being maintained long term by a team with a dwindling bandwidth and bus
factor.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

On Sun, Apr 05, 2020 at 08:46:10PM +0200, Bastian Blank wrote:
> We did not receive a response from DSA to date.  We only got some personal
> remarks from jcristau and weasel on IRC.  They don't want to handle Salsa
> differently and store information.  Also they declared worry about user name
> conflicts.
> 
> We did some changes to remedy those, so we scrapped the changes we had asked
> DSA to do and will check for name conflicts in nm.debian.org before sending
> user creation requests to DSA.

I think the above mischaracterizes DSA's response and opinion:
specifically, there was an engagement with you in #debian-admin on or
about April 3rd in response to this topic specifically.

That said, please consider an approach that would see keycloak used as
an idenitity broker, allowing external users to create accounts using
social identities that are then promoted to full Debian identities (in
LDAP) if they complete the onboarding process. Could be used as
replacement for debsso, could be used for wiki, could be used for
debconf, could be used for salsa.

Thanks,

Luca

-- 
Luca Filipozzi

Salsa as authentication provider for Debian

[Bastian Blank]

Dear Debian fellows

Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the
following plan.  At the same time we declare the following services as EOL:
- sso.debian.org and
- parts of the Salsa self service interface.

We asked DPL, NM, DSA and the Salsa admins already for feedback about what we
intend to do.

We mostly got positive feedback from them, with some reservations about the
user renames.

We did not receive a response from DSA to date.  We only got some personal
remarks from jcristau and weasel on IRC.  They don't want to handle Salsa
differently and store information.  Also they declared worry about user name
conflicts.

We did some changes to remedy those, so we scrapped the changes we had asked
DSA to do and will check for name conflicts in nm.debian.org before sending
user creation requests to DSA.

Regards,
Enrico and Bastian

## Current state

- We have multiple user sources:
  - Debian LDAP,
  - Salsa (which syncs DD from Debian LDAP) and
  - "Alioth" guest "LDAP" for sso.debian.org.
- We have no way to rename users, neither within the Debian LDAP, nor Salsa.
  Renames require a complete new user.
- A person transitioning between non-DD and DD needs a new user and loses all
  state.
- Guest users on Salsa are forced to end with `-guest`.

## Highlevel plan

- 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.
- Salsa allows user renames and drops namespace rules for users (i.e., no more
  requirement for -guest suffix).
- 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.

## Fixed problems

- We get a user source everyone can use both as service provider and user.
- Users can rename themselves before becoming DDs, and retain all information
  both on Salsa and on other services. This also works while transitioning
  between non-DD and DD, and back.

## Corner cases

The Salsa and LDAP databases don't need to be in sync:

- The interaction between the two namespaces only happens when the Salsa
  namespace provides the value for a new DD's LDAP UID. By using salsa as
  default for LDAP UID, we keep the names roughly in sync for convenience
- Conflicts can happen when a prospective new DD has a Salsa username that
  corresponds to an already allocated LDAP uid, and they can be detected and
  handled on nm.debian.org before account creation: people can be told that
  their salsa username is already in use in LDAP, and get a chance to rename it.
- If one renames their Salsa account after becoming DD, someone else could
  start using the old name and exploit the confusion. This would be a rare
  occurrence, and Salsa admins can lock the malicious account if that happens.

People can rename their account on Salsa even after the account exists in LDAP,
since the OIDC identifying information would be the subject, which is the
GitLab internal user ID, which is preserved across renames.

nm.debian.org will provide official membership information to Salsa, so the
Debian group on Salsa will remain, showing DD status.

## Required changes

### Salsa

- Enable sign-on and allow user rename (last step).
- Remove user support from Salsa self service interface.

### Salsa user sync

- Use nm.debian.org as data source for official DD status.
- Add/remove @debian.org e-mail addresses in user information, from
  nm.debian.org

### nm.debian.org

- Support OIDC to get subject, username, display name and e-mail address for
  users.
- Supply information about DD for consumption by Salsa user sync.
- Check for username conflicts.

### sso.debian.org

- Authenticate via OIDC to provide certificate management for a transition
  period, until all sso-using services have migrated to OIDC

## Exit plan

Should GitLab and/or Salsa become unmaintainable, what do we need to migrate
away?

We can export username, e-mail addresses, group membership and OIDC subject
into a new system.  Passwords may not be portable.

Most OIDC using services allow multiple authentication providers out of the
box, so adding a new authentication system can be straightforward. If replacing
Salsa, the issue would be to map user-related information from Salsa's OIDC
subject to whatever the new system uses, and data can be exported from Salsa to
help creating such mapping lists services can use to transition.

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!