Re: Salsa as authentication provider for Debian

[Russ Allbery]

Luca Filipozzi  writes:

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

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

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

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

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

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

too many acronyms [was: Testing Discourse for Debian]

[Luca Filipozzi]

On Fri, Apr 10, 2020 at 03:26:16PM -0400, rhkra...@gmail.com wrote:
> On Friday, April 10, 2020 02:59:59 PM Neil McGovern wrote:
> > For a little while, I've been keen to see how we can improve our
> > communication methods, both to make it more accessible to newcomers 
> 
> Hmm, from the peanut gallery, if you really want things accessible to 
> newcomers, it would be nice if fewer abbreviations were used -- things like 
> DPL, CP, SP, ...
> 
> I'm not particularly talking to you, but more to the participants in the 
> "Salsa as authentication provider for Debian" thread.

Good point. There's a mix of Debian and Identity acronyms in that
thread. Here's a couple of links to help, I hope:

https://www.identropy.com/blog/iam-blog/bid/77844/commonly-used-acronyms-in-identity-and-access-management

https://wiki.debian.org/Glossary

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

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

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

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

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

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

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

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

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

-- 
Luca Filipozzi

Wrapping up the Salsa as OIDC provider proposal

[Enrico Zini]

Hello,

I'll try to summarise thread with the proposal to try wrapping it up and
moving on.

The proposal: https://lists.debian.org/20200405184610.ga581...@waldi.eu.org
More details here: 
https://lists.debian.org/20200407140246.jpflo4zusyr2w...@enricozini.org

I am not going into the advantages of the "Salsa as OIDC" provider
approach, nor into summarising the brainstorming that happened about how
this improvement could either combine with other things or could merge
into a longer-term SSO strategy: I am only focusing on blockers. People
in this thread have already started thinking about incremental
improvements to this proposal and about other proposals, and that is
*great*. I wouldn't want work to *end* at this: I want work to
*begin* from this.

The current situation with Single Sign-On in Debian sits in a spectrum
between painful and useless.

The painful side is nm.debian.org, where we force people to use it,
leaving them no other choice. https://wiki.debian.org/DebianSingleSignOn
does a great job of listing workarounds for all the shortcomings, but
currently gaining access to nm.debian.org might be for some people the
most complex, frustrating, and time consuming step towards becoming DD
or DM.

I have for long being considering taking contributors.debian.org
offline: it's irresponsible to keep that service running if people can't
log in to manage their accounts. The Salsa as OIDC provider proposal is
something I'd rather work on, than taking the service offline.

Other services in the Debian federation are instead implementing their
own account management (like DebConf), or looking into directly
authenticating via OIDC against Salsa anyway, like DebianSocial.

I see using Salsa as OIDC provider as a mitigating step that would
leave Debian with a useful Single Sign-On, without blocking further
progress. Waiting longer means either closing services or scattering the
federation into ad-hoc solutions.

I solicited feedback to see if, for some reason, this step would make
matters *worse* than the status quo, or make it *harder* to migrate
onwards to something else.

I'm summarising here the concerns that have been raised and how they've
been addressed.



* There are better solutions out there, like Keycloak or Lemon LDAP NG

It would be great to have them. In the meantime, using Salsa as OIDC
provider does not seem to be getting in the way of their potential
adoption in the future.

It does not seem that we would end up worse than we are now in that
respect, and the next iteration of SSO in Debian is free to start at any
time.

See: https://lists.debian.org/20200407072834.2wcqldditbnnv...@enricozini.org



* There was work done on using Lemon LDAP NG plus Nacho[1]

There was indeed, and Debian has never managed to put together enough
energy to deploy it. I strongly want to thank Alexander Wirt and Birger
Schacht for working on it, and sadly it never grew into something with
enough support in the project to get deployed and maintained.

This has stalled for long enough, and there is no indication that it
could get deployed anytime soon.



* Migrating to Salsa as OIDC provider would give us an imperfect but
  good enough local optimum, and we will get stuck in that

Perfect is the enemy of good.

Blocking a workable proposal for incremental improvement in case it
turns out to be good enough, seems inconsistent to me give the current
state of single sign-on in Debian.

We are not proposing Salsa as the ultimate solution, but as a fix for
the current situation, that does not prevent moving on to something
else.

See: https://lists.debian.org/20200409074438.wrb2csrsq2wzb...@enricozini.org



* There might be other solutions more secure than Gitlab

I would find it hard to argue that the current sso.debian.org codebase
is better than Gitlab, so we would be doing no worse than now.

Additionally, the whole SSO ecosystem has always been considered
somewhat untrusted and kept outside of the security perimeter of
sensitive Debian operation, and this is not going to change with our
proposal.

See: https://lists.debian.org/20200410074045.yfwjnhbegm3dn...@enricozini.org



* User information may get locked into Gitlab's database format

Gitlab has an API and enough user export features to easily extract
anything from it, with the exception of passwords, as one would expect.



* Are we losing support for client certs? How do service providers
  migrate?

I will update sso.debian.org to consume OIDC auth instead of the current
post-alioth user database, and act as a CA for the services that keep
using client certificates for the time being.

Services can implement OIDC authentication via either the features
available in their programming stacks, or via apache modules.

See: https://lists.debian.org/20200407165135.joe2vvl2mipce...@enricozini.org



* How about spam accounts on Salsa?

The proposal makes no changes, for the better or the worse, in this
respect.

See: 

Re: Salsa as authentication provider for Debian

[Felix Lechner]

Hi,

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

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

Kind regards
Felix Lechner

Re: Salsa as authentication provider for Debian

[Enrico Zini]

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

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

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

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


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

The proposed workflow is that:

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

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

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

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


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

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


Enrico

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


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Julien Cristau]

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

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

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

Cheers,
Julien

Re: Salsa as authentication provider for Debian

[Xavier]

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

Hi,

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

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

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

Re: Testing Discourse for Debian

[rhkramer]

On Friday, April 10, 2020 02:59:59 PM Neil McGovern wrote:
> For a little while, I've been keen to see how we can improve our
> communication methods, both to make it more accessible to newcomers 

Hmm, from the peanut gallery, if you really want things accessible to 
newcomers, it would be nice if fewer abbreviations were used -- things like 
DPL, CP, SP, ...

I'm not particularly talking to you, but more to the participants in the 
"Salsa as authentication provider for Debian" thread.


> and to
> take advantage of more featureful tooling than has been traditionally
> possible with email lists.

Testing Discourse for Debian

[Neil McGovern]

Hi folks,

For a little while, I've been keen to see how we can improve our
communication methods, both to make it more accessible to newcomers and to
take advantage of more featureful tooling than has been traditionally
possible with email lists.

As such, I set up an instance of Discourse[0] at
https://discourse.debian.net, and am now asking for a wider input on if
this is something the project wishes to use and if I should spend my
time pursuing.

FAQ
===

Is it Free Software?
  Yes. It's GPLv2+.

Who else uses it?
  Lots of people. GNOME, Mozilla, Ubuntu, Fedora to name a few

What about the mailing lists?
  This may or may not be a replacement for any particular list. I suspect
  there are some thet would benefit greatly from having Discourse be the
  primary interaction, and other places where this would be less suitable.

Be specific!
  Ok... I think debian-user, debian-vote and possibly debian-project would
  be better off in Discourse. I think debian-devel-announce should stay as
  an email list (for now). However, I am not suddenly proposing that we shut
  those lists down. The aim of this exercise is to see if Discourse would
  work well for us.

Email is still important to me!
  Fine, you can interact with Discorse by email rather than the web
  interface. It should be noted however, that there is not 1:1 feature
  partiy with email and the web interface, as Discorse does things that
  can't easily be done with email. For the majority of users though,
  email interaction should be "good enough".

Why are you doing this?
  I have two motivations. First, is moderation. Discourse has built in tools
  to allow community moderation on a much better scale than our email lists.
  Secondly, I genuinely believe that ease of access to new contributors is
  of paramount importance to the project.

What about X software instead?
  Feel free to explore other solutions. I've already done evaluations, and
  I'm pretty much set on this as the correct way forward. If there is
  insufficient interest in moving forward with Discourse, I'll leave it to
  others to invest time.

What about forums.debian.net?
  I have no interest in interacting with a community of users and
  moderators who allow blatent Code of Conduct violations to go
  unchecked.

What's next?
  I'd appreciate people testing Discourse. If you have any questions, then
  I'm happy to answer them.

Thanks,
Neil

[0] https://www.discourse.org/


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

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

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

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

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

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

--Sam

Re: Salsa as authentication provider for Debian

[Russ Allbery]

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

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

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

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

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

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

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

Java is already maintained by a team.

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

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

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

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

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

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

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

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Luca Filipozzi]

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

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

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

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

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

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

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

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

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

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

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

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

-- 
Luca Filipozzi

Re: Salsa as authentication provider for Debian

[Sam Hartman]

Hi.  Speaking very much as an individual.

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

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

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

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

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

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

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

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

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

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

--Sam

Re: Draft Delegation for the Community Team

[Scott Kitterman]

On Friday, April 10, 2020 9:14:43 AM EDT Sam Hartman wrote:
> TL;DR: The concern Scott raises is a good one, and I think he caught me
> out on a wording problem in the delegation text.
> 
> > "Scott" == Scott Kitterman  writes:
> Scott> Constitution 5.1.4 give the DPL the power to "Make any
> Scott> decision for whom noone else has responsibility."  Some of
> Scott> the items listed seem to be things that the DPL has
> Scott> historically done, like "respond to concerns raised by
> Scott> members of the project or people interacting with them".
> 
> In section 5.1.1, the constitution explicitly forbids the DPL from
>  second guessing a decision ("withrawing the delegation of the
>  decision is the wording used in the constitution) once *that
>  specific decision* is made by the delegates.
>  I think that's the thing that the DPL absolutely cannot do.
> 
> Similarly, I think that the DPL cannot delegate things that are under
> the exclusive authority of individual developers, the TC, or the
> secretary.  Second guessing decisions or having the DPL violate those
> separation of powers would be highly problematic.
> 
> Beyond that, I think we should assume flexibility in section 5.1.4 and
> allow delegation text to be written either in a manner that precludes
> the DPL from being involved while the delegation stands, or in a manner
> that makes things be a shared responsibility.
> If people decide to take a hard line on 5.1.4 and say that we cannot
> write delegation text to permit the DPL and a team to work together on
> an issue, then I'd be happy to try to get support to reword 5.1.4 after
> my DPL term expires.
> 
> That said, it's often a very good idea for the DPL to hand something
> over to a team and let them full control.
> It empowers people and provides an important separation of
> responsibility.
> 
> 
> Scott> Have you assessed the potential constraints this delegation
> Scott> might place on future DPLs?  What is your perspective on
> Scott> things the DPL has traditionally done that will now be
> Scott> delegated to this team?
> 
> I did make that assessment and tried to write  text that made it clear
> which responsibilities were exclusive, but I think I misfired.
> 
> I think the following responsibilities are exclusive to the team:
> >> * To coordinate responses (both inside and outside the project)
> >> to ongoing harassment of the Debian community as a whole or
> >> portions there-of; including working with additional volunteers
> >> when the community team's members are insufficient.
> 
> The DPL can be involved,  but the CT is leading this.
> The CT gets to decide how involved the DPL is.
> This year, DAM and DPL were leading a lot of the coordination with other
> orgs, and turning this over to the CT is an explicit decision.
> 
> >> * To work with event organisers to make sure that Debian Events
> >> have adequate incident response teams to respond to any concerns.
> 
> I don't think DPLs have traditionally done this, and I think giving the
> CT (and event organizers)  seem like a good fit for this.
> 
> The following responsibilities are intended to be shared.
> 
> >> * To respond to concerns raised by members of the project or
> >> people interacting with them, working with individuals to help
> >> them.
> 
> my intent was that  if you write to the DPL, the DPL responds.
> If you write to the CT, the CT responds.
> If you write to both, they cooperate.
> I agree the above bullet doesn't say that; good catch on your part.
> 
> >> * To work with teams responsible for communications channels
> >> within the community such as listmasters, the owner of the Bug
> >> Tracking System, administrators of Debian Planet and others to
> >> provide advice; where desired by these teams, helping to deal
> >> with contentious and difficult issues that impact the community.
> 
> I think the DPL can provide advice if they like, and I think that bullet
> is fine.
> 
> >> * To work with the DPL, Debian Account Managers and others to
> >> provide advice on interpreting the Code of Conduct.  Such advice
> >> may form the basis of interpretations of the Code of Conduct that
> >> help teams in the project set policy around community standards.
> 
> That was explicitly worded not to make it an exclusive responsibility of
> the CT.
> 
> >> * To write reports to other teams such as the Planet Admins,
> >> Listmasters, or Debian Account Managers in response to extreme
> >> incidents or repeated patterns of problematic behavior.
> 
> It would be amusing if we could  prevent anyone but the CT from writing
> reports.
> 
> So, if this all makes sense, I'll try to work on wording for the first
> bullet point that makes it clear you can still write to the DPL if you
> like.
> 
> Thanks so much for bringing this up.

That all seems reasonable.  Thanks,

Scott K


signature.asc
Description: This is 

Re: Draft Delegation for the Community Team

[Sam Hartman]

TL;DR: The concern Scott raises is a good one, and I think he caught me
out on a wording problem in the delegation text.

> "Scott" == Scott Kitterman  writes:


Scott> Constitution 5.1.4 give the DPL the power to "Make any
Scott> decision for whom noone else has responsibility."  Some of
Scott> the items listed seem to be things that the DPL has
Scott> historically done, like "respond to concerns raised by
Scott> members of the project or people interacting with them".

In section 5.1.1, the constitution explicitly forbids the DPL from
 second guessing a decision ("withrawing the delegation of the
 decision is the wording used in the constitution) once *that
 specific decision* is made by the delegates.
 I think that's the thing that the DPL absolutely cannot do.

Similarly, I think that the DPL cannot delegate things that are under
the exclusive authority of individual developers, the TC, or the
secretary.  Second guessing decisions or having the DPL violate those
separation of powers would be highly problematic.

Beyond that, I think we should assume flexibility in section 5.1.4 and
allow delegation text to be written either in a manner that precludes
the DPL from being involved while the delegation stands, or in a manner
that makes things be a shared responsibility.
If people decide to take a hard line on 5.1.4 and say that we cannot
write delegation text to permit the DPL and a team to work together on
an issue, then I'd be happy to try to get support to reword 5.1.4 after
my DPL term expires.

That said, it's often a very good idea for the DPL to hand something
over to a team and let them full control.
It empowers people and provides an important separation of
responsibility.


Scott> Have you assessed the potential constraints this delegation
Scott> might place on future DPLs?  What is your perspective on
Scott> things the DPL has traditionally done that will now be
Scott> delegated to this team?

I did make that assessment and tried to write  text that made it clear
which responsibilities were exclusive, but I think I misfired.

I think the following responsibilities are exclusive to the team:

>> * To coordinate responses (both inside and outside the project)
>> to ongoing harassment of the Debian community as a whole or
>> portions there-of; including working with additional volunteers
>> when the community team's members are insufficient.

The DPL can be involved,  but the CT is leading this.
The CT gets to decide how involved the DPL is.
This year, DAM and DPL were leading a lot of the coordination with other
orgs, and turning this over to the CT is an explicit decision.

>> 
>> * To work with event organisers to make sure that Debian Events
>> have adequate incident response teams to respond to any concerns.

I don't think DPLs have traditionally done this, and I think giving the
CT (and event organizers)  seem like a good fit for this.

The following responsibilities are intended to be shared.

>> * To respond to concerns raised by members of the project or
>> people interacting with them, working with individuals to help
>> them.

my intent was that  if you write to the DPL, the DPL responds.
If you write to the CT, the CT responds.
If you write to both, they cooperate.
I agree the above bullet doesn't say that; good catch on your part.

>> * To work with teams responsible for communications channels
>> within the community such as listmasters, the owner of the Bug
>> Tracking System, administrators of Debian Planet and others to
>> provide advice; where desired by these teams, helping to deal
>> with contentious and difficult issues that impact the community.

I think the DPL can provide advice if they like, and I think that bullet
is fine.


>> * To work with the DPL, Debian Account Managers and others to
>> provide advice on interpreting the Code of Conduct.  Such advice
>> may form the basis of interpretations of the Code of Conduct that
>> help teams in the project set policy around community standards.

That was explicitly worded not to make it an exclusive responsibility of
the CT.

>> * To write reports to other teams such as the Planet Admins,
>> Listmasters, or Debian Account Managers in response to extreme
>> incidents or repeated patterns of problematic behavior.

It would be amusing if we could  prevent anyone but the CT from writing
reports.

So, if this all makes sense, I'll try to work on wording for the first
bullet point that makes it clear you can still write to the DPL if you
like.

Thanks so much for bringing this up.

Re: Salsa as authentication provider for Debian

[Sam Hartman]

> "Luca" == Luca Filipozzi  writes:

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

>> the future?

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

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

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

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

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

Re: Salsa as authentication provider for Debian

[Bastian Blank]

Hi Luca

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

And here the problems begin.

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

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

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

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

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

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

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

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

Just random bugs.

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

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

The latest installation doc is pretty specific:

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

Regards,
Bastian

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

Re: Salsa as authentication provider for Debian

[Enrico Zini]

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

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

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

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

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


Enrico

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


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

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

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

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

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

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

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

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

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

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

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


Enrico

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


signature.asc
Description: PGP signature

Re: Salsa as authentication provider for Debian

[Enrico Zini]

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

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

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

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


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

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

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

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


Enrico

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


signature.asc
Description: PGP signature