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

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

Salsa as authentication provider for Debian

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

Contents

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

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

#11642

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

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

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

#11643

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

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

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

#11659

Hi,

On Fri, Apr 10, 2020 at 12:49 AM Enrico Zini <enrico@enricozini.org> 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

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

#11663

On 10 April 2020 12:05:42 BST, Felix Lechner <felix.lechner@lease-up.com> 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

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

#11665

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) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

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

#11667

On Sat, 11 Apr 2020 12:02:40 +0200
Jonathan Carter <jcc@debian.org> 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.

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

#11669

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

>>>>> "Michael" == Michael Lustfield <michael@lustfield.net> 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.nchdmlkk6zdj7l2j@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

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

#11586

Hi Luca

On Mon, Apr 06, 2020 at 04:09:38PM +0000, 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

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

#11621

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 +0000, 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

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

#11644

Hi Luca

On Wed, Apr 08, 2020 at 03:18:58PM +0000, 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

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

#11650

On Fri, Apr 10, 2020 at 12:06:42PM +0200, Bastian Blank wrote:
> On Wed, Apr 08, 2020 at 03:18:58PM +0000, 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

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

#11583

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

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

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

#11589

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

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

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

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.

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

<as usual, sorry for my poor English>

My 2 cents...

Cheers,
Xavier (yadd)

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

#11590

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

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,...
> 
> <as usual, sorry for my poor English>

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

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

#11591

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,...
>>
>> <as usual, sorry for my poor English>
> 
> 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

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

#11592

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

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

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

#11593

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)

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

#11594

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

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

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

#11595

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 ;-)

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

#11624

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

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

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

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

csiph-web