Salsa as authentication provider for Debian

classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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!

Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Enrico Zini
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. 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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Holger Levsen-2
In reply to this post by Bastian Blank
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Luca Filipozzi
In reply to this post by Enrico Zini
On Mon, Apr 06, 2020 at 08:38:59PM +0200, Enrico Zini 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. 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

Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Michael Lustfield
In reply to this post by Enrico Zini
On Mon, 6 Apr 2020 20:38:59 +0200
Enrico Zini <[hidden email]> 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. 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

Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Bastian Blank
In reply to this post by Luca Filipozzi
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

Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Enrico Zini
In reply to this post by Luca Filipozzi
On Mon, Apr 06, 2020 at 07:07:26PM +0000, 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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Geert Stappers-2
On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote:

> On Mon, Apr 06, 2020 at 07:07:26PM +0000, 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

Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Xavier Guimard-3
In reply to this post by Bastian Blank
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)

Reply | Threaded
Open this post in threaded view
|

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,...
>
> <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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Xavier Guimard-3
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

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Xavier Guimard-3
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)



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Xavier Guimard-3
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 ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Michael Lustfield
In reply to this post by Enrico Zini
On Tue, 7 Apr 2020 13:50:06 +0200
Enrico Zini <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Paul Wise via nm
In reply to this post by Bastian Blank
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

Reply | Threaded
Open this post in threaded view
|

Re: Salsa as authentication provider for Debian

Xavier Guimard-3
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?

12345