Re: Salsa as authentication provider for Debian
Le 08/04/2020 à 17:28, Luca Filipozzi a écrit : > reminder: I'm replying linearly and from what I know (keycloak, SAML and > OIDC). > > > On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: >> Le 05/04/2020 à 20:46, Bastian Blank a écrit : >> I can help if you want to use lemondap-ng (LLNG: >> https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng) > > Cool. > >> This requires to change all services. Using a SSO is easier here: >> gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app >> without having to change to many things. LLNG handlers are directly >> included in Apache/Nginx configuration and provides HTTP-headers to the >> web app. > > Or Apache modules like mod-auth-openidc (OIDC) or mod-auth-mellon > (SAML). Hi, LLNG handlers are apache modules. The difference is that they don't only manage authentication but also authorizations >> Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and >> any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal >> then becomes transparent > > Keycloak, as a broker, is similar. Service provider can be using one > protocol and the identity provider another. > >> It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps >> more safe to manage users elsewhere (custom app) and make GitLab a slave >> of SSO system. LLNG provides a plugin engine for that. > > Gitlab can use OIDC for OmniAuth, so it can authenticate against any > OIDC-compliant IdP, LLNG and Keycloak included. > >> NB: KeyCloak is free but this needs to stay in last version, else you >> need a RedHat-SSO support. LLNG is totally free, written in Perl and JS; >> and Debian has a lot of Perl-Gurus ;-). > > Redhat has the distinction (thankfully) of not following a 'freemium' > model (at least for Directory389 and Keycloak). The features available > in RedHat SSO and Keycloak are identical. Redhat SSO lags behind > Keycloak but may include fixes not yet ported to Keycloak. Keycloak is > also totally free and, yes, is written in Java. > >> I can give some accounts to demo platform: https://auth.openid.club/ >> [dev platform, so sometime broken...] or install an instance in a Debian >> machine if you want to try it. > > > Please work with Michael Lustfield (IRC MTecknology) as he is also > interested in setting upa Debian-specific instance of LLNG. With pleasure ! >> Resume of proposition: >> * all users managed by SSO; > > Agree! > >> * self-registration authorized with "-guest" >>in a distinct LDAP branch > > More thought required but don't disagree. > >> * GitLab becomes a slave of SSO using SAML (or OIDC) > > Agree! > >> * other applications are protected by handlers/GateKeepers. If LLNG is >>chosen, just to add few lines in Nginx configuration > > Agree and/or mod-auth-openidc/mod-auth-lemon, etc. > >> * new applications can be protected using handlers, SAML, CAS, OIDC,... > > Agree but with order of preference being OIDC, SAML and... way over > there, almost too distant to see... CAS. Of course, old protocol. Choosing between handlers and federation protocols depends on how we want to manage authorizations: * centralized authorization: handlers (authorization managed by manager application, websites are filtered globally or using regxp on URLs * managed in application: both way This is the choice to do (both ways are possible simultaneously) >> > > Very helpful response! Thanks ;-) --- /me has worked for 15 years on Identity and Access Management (IAM) topics
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:50:00PM +0200, Tollef Fog Heen wrote: > >(There's also the wiki account lifecycle, but that's completely separate >and doesn't interact with any of the others, so we might want to keep >that outside the discussion for now.) Agreed! (as a wiki admin) -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Re: Salsa as authentication provider for Debian
]] Sam Hartman > There's another flow. Contributors interact with DSA in some process I > do not fully understand to get guest accounts on porter boxes etc. https://dsa.debian.org/doc/guest-account/ I'd like to see a proposal on how to avoid namespace clashes between guest and non-DD salsa accounts? (There's also the wiki account lifecycle, but that's completely separate and doesn't interact with any of the others, so we might want to keep that outside the discussion for now.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 03:18:39PM +0200, Enrico Zini wrote: > On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote: > > > > I understand you want to recognize DDs from other contributors, but why? > > > Does it help you with permissions, does it help understand who someone > > > is, or is it a habit that has been there since Alioth? > > > > For me, it's easier to trust a DD than a non-DD, so I'll grant a role > > with higher permission if they request to join a team/project. > > I think this has ups and downs. Another view point: I don't think that one's username should change as one's role(s) with the organization changes. If we could avoid that... -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 06:23:29AM -0400, Sam Hartman wrote: > Debian has two account life cycle work flows that we're reasonably happy > with (or at least not proposing to change now). > > The first is the account life cycle for developers. DAM sends a signed > ticket to keyring-maint and DSA, and accounts get created or locked. > Developers send signed tickets to some combination of folks to deal with > name changes. > > There's another flow. Contributors interact with DSA in some process I > do not fully understand to get guest accounts on porter boxes etc. The third flow being 'guests' in Debian LDAP. > These account life cycle flows are too heavy-weight for several tasks > that we find: > > * someone wants an account on salsa for hosting projects or interacting > with projects there. > > * Someone wants to manage their contributors.debian.org info > > * Someone wants to enter the nm process. (This will eventually get to > the heavy weight account life cycle, but we want starting the > application to involve zero signed RT tickets) > > * People want to run services that consume Debian community accounts. > > So, it's not just that we need an SSO provider. > we need a light weight account life cycle system that will fit into our > SSO strategy. With keycloak (or LLNG) set up as as a broker, then user account self-creation is possible (caveat waldi's comments about attrs and groups which requires more investigation). > It also needs to eventually interact with nm, which will allow it to > work with the existing account life cycle flow for developer accounts. > But given Enrico's interest, I think it's safe to say that nm > interactions are being considered. With keycloak, when a user becomes a DD, we add an LDAP account and ask the user to merge on next login via keycloak workflows or we use keycloak APIs to merge for them. > so, a lot of people are jumping up and down talking about particular SSO > strategies focusing on the SSO aspects of those strategies. No one is jumping, thank you. > Where as what is the most important gaps for our project surround the > account life cycle stuff. > > And for all its faults, Gitlab has a very easy story for this. > > You can maintain an account in gitlab with a username and password. > > In the long run you can also front gitlab with something else provided > that you have a something else that does account lifecycle > management. > > As a reminder, no one is talking about having DSA trust gitlab to > control access to the archive or Debian machines. I think we all > cringe thinking about that. Well, given this DPL statement, shall I continue answering other emails in this thread or no? That is the question now. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 05:28:37PM +0200, Enrico Zini wrote: > On Wed, Apr 08, 2020 at 03:00:31PM +, Luca Filipozzi wrote: > > > > Question: is there something in the proposed Salsa plan that somehow > > > blocks experimenting with, introducing, or migrating to Keycloak in the > > > future? > > > > The further we go down one path, the harder, in my opinion, to change > > later. > > I think we're not really going "down one path": we're trying to dig > ourselves "out of one pit". > > I'll have to repeat the question: is there something specific in the > proposed Salsa plan, that somehow blocks experimenting with, > introducing, or migrating to Keycloak or some other solution in the > future? I think introduction of the broker is the compelling use case. I appreciate that you may not view that as sufficient compelling. Additionally, I'd prefer keeping SPs separate from IdPs, have them speak to each other using standard protocols, etc. I don't view making Gitlab an IdP as appropriate. > From what I can see so far, we're starting a migration to OIDC, removing > one of 3 user databases, adopting more standards, and doing some general > cleanup along the way, which makes me think Salsa could be considered an > iterative step towards a migration to anything else. Very good outcomes, to be sure. > If you're instead generally expressing a fear that once we migrate to > Salsa, we'll be in a local optimum that is going to be considered good > enough to be worth bothering migrating to anything else, then I would > argue that the problem wouldn't be having moved to Salsa as an OIDC > provider, and rather that the next step that is proposed wouldn't be > bringing enough compelling advantages to the problem at hand. Indeed, a local optimum is worrisome. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
reminder: I'm replying linearly (in this case, at the end of a chain of email) and from what I know (keycloak, SAML and OIDC). On Tue, Apr 07, 2020 at 04:08:37PM +0200, Xavier wrote: > Le 07/04/2020 à 16:02, Enrico Zini a écrit : > > On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote: > > > >> With a SSO, I don't think it's a good thing to have a protected app as > >> user database (even if it's possible). Then migration consists to > >> extract gitlab accounts and push them in LDAP (2 branches, one for DD, > >> one for guests) > > > > Ok, please help me to see where that would be an issue. > > It's not an issue. With a SSO we shall probably change this: salsa > accounts will be created on-the-fly using federation mechanism, then > there is only one user database (LDAP with 2 branches) The Debian LDAP is atypical in a variety of ways, it's true. Like LLNG, Keycloak use mappers to pull / transform as necessary. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
reminder: I'm replying linearly and from what I know (keycloak, SAML and OIDC). On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > Le 05/04/2020 à 20:46, Bastian Blank a écrit : > I can help if you want to use lemondap-ng (LLNG: > https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng) Cool. > This requires to change all services. Using a SSO is easier here: > gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app > without having to change to many things. LLNG handlers are directly > included in Apache/Nginx configuration and provides HTTP-headers to the > web app. Or Apache modules like mod-auth-openidc (OIDC) or mod-auth-mellon (SAML). > Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and > any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal > then becomes transparent Keycloak, as a broker, is similar. Service provider can be using one protocol and the identity provider another. > It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps > more safe to manage users elsewhere (custom app) and make GitLab a slave > of SSO system. LLNG provides a plugin engine for that. Gitlab can use OIDC for OmniAuth, so it can authenticate against any OIDC-compliant IdP, LLNG and Keycloak included. > NB: KeyCloak is free but this needs to stay in last version, else you > need a RedHat-SSO support. LLNG is totally free, written in Perl and JS; > and Debian has a lot of Perl-Gurus ;-). Redhat has the distinction (thankfully) of not following a 'freemium' model (at least for Directory389 and Keycloak). The features available in RedHat SSO and Keycloak are identical. Redhat SSO lags behind Keycloak but may include fixes not yet ported to Keycloak. Keycloak is also totally free and, yes, is written in Java. > I can give some accounts to demo platform: https://auth.openid.club/ > [dev platform, so sometime broken...] or install an instance in a Debian > machine if you want to try it. Please work with Michael Lustfield (IRC MTecknology) as he is also interested in setting upa Debian-specific instance of LLNG. > Resume of proposition: > * all users managed by SSO; Agree! > * self-registration authorized with "-guest" >in a distinct LDAP branch More thought required but don't disagree. > * GitLab becomes a slave of SSO using SAML (or OIDC) Agree! > * other applications are protected by handlers/GateKeepers. If LLNG is >chosen, just to add few lines in Nginx configuration Agree and/or mod-auth-openidc/mod-auth-lemon, etc. > * new applications can be protected using handlers, SAML, CAS, OIDC,... Agree but with order of preference being OIDC, SAML and... way over there, almost too distant to see... CAS. > Very helpful response! -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 03:00:31PM +, Luca Filipozzi wrote: > > Question: is there something in the proposed Salsa plan that somehow > > blocks experimenting with, introducing, or migrating to Keycloak in the > > future? > > The further we go down one path, the harder, in my opinion, to change > later. I think we're not really going "down one path": we're trying to dig ourselves "out of one pit". I'll have to repeat the question: is there something specific in the proposed Salsa plan, that somehow blocks experimenting with, introducing, or migrating to Keycloak or some other solution in the future? From what I can see so far, we're starting a migration to OIDC, removing one of 3 user databases, adopting more standards, and doing some general cleanup along the way, which makes me think Salsa could be considered an iterative step towards a migration to anything else. If you're instead generally expressing a fear that once we migrate to Salsa, we'll be in a local optimum that is going to be considered good enough to be worth bothering migrating to anything else, then I would argue that the problem wouldn't be having moved to Salsa as an OIDC provider, and rather that the next step that is proposed wouldn't be bringing enough compelling advantages to the problem at hand. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
reminder: I'm answering these linearly and i'm speaking from what I know
(keycloak) not what I don't (LLNG). I expect LLNG is generally similar.
On Tue, Apr 07, 2020 at 08:53:47AM +0200, Bastian Blank wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that are then promoted to full Debian identities (in
> > LDAP) if they complete the onboarding process.
>
> You are proposing a different idea, however you are not yet proposing a
> project with actionable items on it. If you think this is worthwhile,
> please provide at least the following things:
Responding to "here's an idea: try keycloak" with "publish a full plan"
creates a mountain when we're just at the foothills. I appreciate that,
from your perspective, you've been at this for a year and are
frustrated. I'll respond briefly to these below but, if we want a
fulsome plan, we should create a wiki page with the use cases and
evaluate things against the use cases a bit more.
> - Workflows, esp non-DD to DD and vice versa.
non-DDs can create accounts locally in keycloak and/or tie them to
social identity providers ("let them use existing credentials"). If they
becomee DDs, later, we add them to LDAP and cause them to 'merge' their
accounts on next login (or we use keycloak's API).
> - Self service, e.g. user signup, how do users add OIDC clients, how add
User signup is described above. Individual services could accept all
users or could require specific role assignment. Service owners would
then need to decide on role assignment mechanism.
I've not tried empowering non-admin users to add service providers
to a keycloak IdP. I don't doubt it's possible, just have to try.
> groups/roles to OIDC info.
Yes, keycloak has powerful mapping capability to allow groups/roles to
be exposed as assertions to service providers.
> - Salsa, how should it work together.
Gitlab can use OIDC as an OmniAuth provider.
> - Additional features
> - Who is willing to maintain this long-term
I'm not committing DSA to this but I'm encouraged by their interest in a
demo.
There are at least three people on the thread who are familiary with
SAML/OIDC who are interested in supporting this service.
> - Exit strategy
I'm still at ideation.
> Anyway, I took a quick look into Keycloak.
>
> What I find particular interesting is:
> - they use UUID for user identification
internally, yes. what is passed to a service provider as an identity
assertion can be configured through mapping rules on an SP-by-SP basis
> - users and groups can have arbitrary attributes attached to them,
> however they are not self service
> - it is a complete authorization solution
>
> What isn't so great
> - no particular good admin interface (there are 40+ settings for each
> OIDC client alone)
Nearly all of those settings are auto-populated by exchanging metadata.
In SAML, the SP and the IdP exchange XML documents containing the
metadata. Tedious but works. In OIDC, the SPI and the IdP point to each
other's 'well-known' configuration URLs to pull in the metadata. The
OIDC folks learned from SAML.
> - it can have forms without a required field, which can't be saved at
> all.
Not sure what you're describing, here.
> - jboss. Who considers itself capable of running public jboss
> applications safely and securely?
Yes, there's a general lack of interest in Java and JBoss in our
community.
> Showstopper
> - no self service for group or even OIDC clients
More investigation required, frankly.
> - no U2F (okay, GitLab also still needs to make the step to webauthn)
> - requires Java 8, which is not supported on Debian Buster
This isn't true. I'm running keycloak in a demo for work using
openjdk-11-jre-headless. Their documentation would do well to say Java 8 or
later.
> I was not able to see the killer feature of this setup or at least one
> feature that we must have.
I think the 'killer feature' is independent of Keycloak. It's the
introduction of an identity broker that offers a single place for
service providers to integrate, offers social-to-identity for users,
etc.
--
Luca Filipozzi
Re: Salsa as authentication provider for Debian
I'm working through the responses linearly, so... On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote: > On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote: > > > > I don't know keycloak: what are the maintenance costs, and what would be > > > the benefits over time? > > > > > > Right now, with the proposal waldi just posted, we have very little to > > > no added maintenance cost, possibly negative maintenance cost once we > > > take sso.debian.org and the current handcrafted salsa subscription thing > > > offline. The amount of code deployed compared to the status quo would go > > > *down*. The user interface and user experience for the lot would be good > > > and well known. Gitlab's codebase, while large and complex, is widely > > > deployed, and we already have know-how about it in Debian. Having read the response relating to an audit of gitlab source code, I would question whether gitlab is 'saft'. That said, we'd want similar attestations for LLNG or keycloak. Keycloak has been selected by a number of governments / unis / etc. That's not to say that they did code reviews; it is to say that it is receiving some adoption (which I think will grow). I know more about keycloak than LLNG, so I'll restrict my responses to Keycloak, SAML and OIDC (OpenID Connect). > > Having just joined this conversation, the above is an argument that is > > difficult to refute: one can always argue that 'one in the hand is > > better than one in the bush'. > > Yes :/ I think that's more or less where we are now, unfortunately, > after a year or more failing to find people to deploy and maintain > alternatives. I think people are stepping forward, albeit slowly. > On one hand, client certificate handling in browsers gets worse over > time, and the current sso solution is effectively running on people > collecting all sorts of workaround instructions in the excellent wiki > page at https://wiki.debian.org/DebianSingleSignOn I suggest that we move from client certificate-based authentication to SAML- or OIDC-based authentication. > On the other hand, signing in for non-DDs is a major hurdle that takes > literally weeks, when one can find out how to do it at all. We DDs care > little about that, it's Not Our Problem. That barrier makes joining > nm.debian.org to become a DD a challenge in itself. Other things like > managing one's own information on contributors.debian.org are just not > worth the challenge, and I'm planning to take contributors.d.o offline > soon, because I/we can't, ethically and legally, publish people's > information without giving those people a reasonable chance to control > it. With keycloak, we could: * allow people to create accounts locally in keycloak, and//or * allow people to create accounts tied to other identity providers (Gmail, etc.) This is the 'social-to-identity' concept where an organization wishes to make onboarding of new users as friendly as possible (let them use their existing credentials). If, later, they become a customer (i.e., Debian Developer), then you promote their account from 'social' to 'internal'). > > My DSA colleagues asked for demo and I'm building that up, currently. I > > view this as a positive but not definitive step in the maintenance > > questions. > > > > I appreciate that the idea of using keycloak as an IdB requires everyone > > to shift perspective. > > > > Let me know if you have appetite (or not*) to discuss the above. > > Personally I'm interested in anything that works and that I can have a > very good confidence that somebody will maintain over time. > > I care about maintenance and sustainability more than about anything > else, because I'm the one who's been forced to set up and maintain SSO > in Debian mostly alone for 8 years, because everybody else walked away > from it and I could not. > > OIDC supports various authentication sources, and the Salsa plan > decouples OIDC from LDAP allowing them to evolve independently, removes > custom nonstandard components, and includes the option of migrating away > to something else in the future. In my understanding it enables > experimentation with other systems rather than blocking it. > > Question: is there something in the proposed Salsa plan that somehow > blocks experimenting with, introducing, or migrating to Keycloak in the > future? The further we go down one path, the harder, in my opinion, to change later. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 10:05:19AM -0400, Sam Hartman wrote: > I don't think it blocks your proposal, but I do think that having > something to audit repos and make sure only current dds have access to > certain repos is a valuable user no]eed. > And I think the current-status-permission check need is also valid and > probably more critical. Sure. I seriously think we don't have enough audit tools in Debian, and I'm strongly in favour of having more. With regards of current-status-permission, I checked with waldi, and with some extra work it is possible to add some visible information to the user's page, synced from nm.debian.org, about their official membership status: we can totally have that. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
> "Enrico" == Enrico Zini writes: Enrico> I agree that with the current proposal, the use case of Enrico> "grant a person permission based on their status, which is Enrico> somehow revoked or blocked if the status goes away" becomes Enrico> something we might not be able to do. Fair enough. But there is the use case of sanity check that foo is a dd before granting them permissions today because I'm going to think about it a lot more if they aren't a dd is a valid use case. Also, I do think there are some repos that we really only want a dd writing to. As an example, keyring-maint. Now if something goes bad for keyring maint we're going to notice it, and keyring maint would certainly be in the loop if someone from keyring-maint retired. I don't think it blocks your proposal, but I do think that having something to audit repos and make sure only current dds have access to certain repos is a valuable user no]eed. And I think the current-status-permission check need is also valid and probably more critical.
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote: > > I understand you want to recognize DDs from other contributors, but why? > > Does it help you with permissions, does it help understand who someone > > is, or is it a habit that has been there since Alioth? > > For me, it's easier to trust a DD than a non-DD, so I'll grant a role > with higher permission if they request to join a team/project. I think this has ups and downs. Currently, if someone doesn't have -guest on Salsa, they are either active DDs or locked accounts. The moment a non-"-guest" person loses their DD status, their account gets locked. This is currently causing trouble: when one loses DD status, suddenly they lose access to all their repositories until they get readded to everything with a new -guest account. For repositories that only they controlled, this requires admin intervention and headaches. This has happened, and it's serious enough to make Salsa not suitable for hosting long-term projects at the moment: I don't want to build my projects' ecosystem on something which locks me out the moment I decide to go emeritus, or the moment I get my Debian membership temporarily suspended for whatever reason. I would argue that it would make more sense to grant roles and permissions to people based on their past contributions and reputation, rather than based on current status. I agree that with the current proposal, the use case of "grant a person permission based on their status, which is somehow revoked or blocked if the status goes away" becomes something we might not be able to do. In my opinion this change, rather than opening a new problem, fixes an old, nasty one instead. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
> "Enrico" == Enrico Zini writes: Enrico> On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote: >> Sigh, but it makes sense too. Will nm.d.o have a field which >> reflects the username on salsa? Enrico> It finally will, yes! \o/ Enrico> It's been quite painful not having that mapping so far. Enrico, in addition to your ack/nack collecting, I think it is valuable to collect unmet needs to guide future work. It sounds like multiple people are saying there's a need to easily determine whether at the current time a given username is a dd. In practice removing the -guest thing will make that harder for the common case. I don't know that means it is a blocker, but it does sound like it means that's an area where working to understand and meet that user need independently of your proposal would be good. (And if it is a blocker, obviously it becomes a higher priority.)
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote: > Sigh, but it makes sense too. Will nm.d.o have a field which reflects > the username on salsa? It finally will, yes! \o/ It's been quite painful not having that mapping so far. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:04:59PM +0800, Shengjing Zhu wrote: > > 1. Can you still keep the "-guest" enforcement, so it's still easy to > > recognize who is DD or not on salsa? > > The reason why I ask for this is because > 1. If a -guest account is added to a project in salsa Debian group, > the group name is also shown on the personal profile. > 2. Users can make their profile private, so you don't know what group > they belong to. > 3. To search in the Debian group member page takes too many steps. > > If there's an easy way I'm not aware of, then I'm fine with it. I checked with waldi, and with some extra work it is possible to add some visible information to the user's page, synced from nm.debian.org, about their official membership status. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 8, 2020 at 8:33 PM Bastian Blank wrote: > > Hi Zhu > > On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote: > > 1. Can you still keep the "-guest" enforcement, so it's still easy to > > recognize who is DD or not on salsa? > > No. The guest suffix was meant to avoid collisions with Debian > accounts. And the tool used to enforce it is unmaintained. > > Also the only place that can for sure answer if someone is DD is > nm.debian.org, not Salsa. > Sigh, but it makes sense too. Will nm.d.o have a field which reflects the username on salsa? Although it takes multi steps to figure out the user status when you click a "Request to join" link sent by salsa. -- Shengjing Zhu
Re: Salsa as authentication provider for Debian
Ulrike Uhlig writes: > On 08.04.20 13:50, Shengjing Zhu wrote: >> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote: > >> 1. Can you still keep the "-guest" enforcement, so it's still easy to >> recognize who is DD or not on salsa? > > Could you explain a bit better why you think that this is needed? > > I understand you want to recognize DDs from other contributors, but why? > Does it help you with permissions, does it help understand who someone > is, or is it a habit that has been there since Alioth? I don't know the exact proposed rules here, but I could imagine that without these rules anyone cann fill the namespace of nice Debian user names. And there is the danger that someone hijacks the user name of a Debian user who is still not on Salsa. Or an emeritus name or so. I would also like to have a visible distinction between "trusted" names (where the owner is verified via key) and random names, in one way or the other. Cheers Ole
Re: Salsa as authentication provider for Debian
Hi Zhu On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote: > 1. Can you still keep the "-guest" enforcement, so it's still easy to > recognize who is DD or not on salsa? No. The guest suffix was meant to avoid collisions with Debian accounts. And the tool used to enforce it is unmaintained. Also the only place that can for sure answer if someone is DD is nm.debian.org, not Salsa. > 2. For transition between non-DD and DD, could salsa admin rename the > username by requests? No. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9
Re: Salsa as authentication provider for Debian
On Wed, Apr 8, 2020 at 8:13 PM Ulrike Uhlig wrote: > > Hi! > > On 08.04.20 13:50, Shengjing Zhu wrote: > > On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote: > > > 1. Can you still keep the "-guest" enforcement, so it's still easy to > > recognize who is DD or not on salsa? > > Could you explain a bit better why you think that this is needed? > > I understand you want to recognize DDs from other contributors, but why? > Does it help you with permissions, does it help understand who someone > is, or is it a habit that has been there since Alioth? For me, it's easier to trust a DD than a non-DD, so I'll grant a role with higher permission if they request to join a team/project. -- Shengjing Zhu
Re: Salsa as authentication provider for Debian
Hi! On 08.04.20 13:50, Shengjing Zhu wrote: > On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote: > 1. Can you still keep the "-guest" enforcement, so it's still easy to > recognize who is DD or not on salsa? Could you explain a bit better why you think that this is needed? I understand you want to recognize DDs from other contributors, but why? Does it help you with permissions, does it help understand who someone is, or is it a habit that has been there since Alioth? ulrike
Re: Salsa as authentication provider for Debian
On Wed, Apr 8, 2020 at 7:50 PM Shengjing Zhu wrote: [...] > 1. Can you still keep the "-guest" enforcement, so it's still easy to > recognize who is DD or not on salsa? The reason why I ask for this is because 1. If a -guest account is added to a project in salsa Debian group, the group name is also shown on the personal profile. 2. Users can make their profile private, so you don't know what group they belong to. 3. To search in the Debian group member page takes too many steps. If there's an easy way I'm not aware of, then I'm fine with it. -- Shengjing Zhu
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote: > 1. Can you still keep the "-guest" enforcement, so it's still easy to > recognize who is DD or not on salsa? I'll leave answering these questions to Waldi / Salsa admins. I would like to stick to investing energy in solving problems that we really have, though, so I'm curious: do you have specific reasons in mind for asking to preserve the "-guest" enforcement on Salsa? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote: [...] > ## Highlevel plan > > - Salsa becomes primary source of user info and authentication for secondary > services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing > sso.debian.org. > - Salsa allows user renames and drops namespace rules for users (i.e., no more > requirement for -guest suffix). > - nm.debian.org uses Salsa usernames by default to populate LDAP usernames > when > creating accounts, and stores OIDC subject to strongly correlate between > Salsa and Debian LDAP users. > > ## Fixed problems > > - We get a user source everyone can use both as service provider and user. > - Users can rename themselves before becoming DDs, and retain all information > both on Salsa and on other services. This also works while transitioning > between non-DD and DD, and back. > 1. Can you still keep the "-guest" enforcement, so it's still easy to recognize who is DD or not on salsa? 2. For transition between non-DD and DD, could salsa admin rename the username by requests? For 1, I think it doesn't make the original plan more complicated. For 2, I think it doesn't either, as you already plan to support renaming. -- Shengjing Zhu
Re: Salsa as authentication provider for Debian
TL;DR: In Enrico's terms I'm an ACK not a NACK. I'm also trying to help people considering whether they have blocking objections think about the problems actually facing Debian. I'm noticing a bit of a conflict here between people who are familiar with Debian and people who are familiar with SSO. I think I have a bit of background in the SSO space over the years, and can perhaps try and bridge the gap of understanding. In a lot of SSO situations, the organization has a existing account lifecycle management strategy, and the SSO situation is assisting that. That is, the organization has a existing way to create accounts and deal with entitlements for those accounts. My day job uses Keycloak for that both for our own stuff and with customers. (We use a few other things in certain circumstances, including amusingly enough Gitlab in one instance) but generally tend toward Keycloak. However, that doesn't really describe the Debian situation. Debian has two account life cycle work flows that we're reasonably happy with (or at least not proposing to change now). The first is the account life cycle for developers. DAM sends a signed ticket to keyring-maint and DSA, and accounts get created or locked. Developers send signed tickets to some combination of folks to deal with name changes. There's another flow. Contributors interact with DSA in some process I do not fully understand to get guest accounts on porter boxes etc. These account life cycle flows are too heavy-weight for several tasks that we find: * someone wants an account on salsa for hosting projects or interacting with projects there. * Someone wants to manage their contributors.debian.org info * Someone wants to enter the nm process. (This will eventually get to the heavy weight account life cycle, but we want starting the application to involve zero signed RT tickets) * People want to run services that consume Debian community accounts. So, it's not just that we need an SSO provider. we need a light weight account life cycle system that will fit into our SSO strategy. It also needs to eventually interact with nm, which will allow it to work with the existing account life cycle flow for developer accounts. But given Enrico's interest, I think it's safe to say that nm interactions are being considered. so, a lot of people are jumping up and down talking about particular SSO strategies focusing on the SSO aspects of those strategies. Where as what is the most important gaps for our project surround the account life cycle stuff. And for all its faults, Gitlab has a very easy story for this. You can maintain an account in gitlab with a username and password. In the long run you can also front gitlab with something else provided that you have a something else that does account lifecycle management. As a reminder, no one is talking about having DSA trust gitlab to control access to the archive or Debian machines. I think we all cringe thinking about that. --Sam signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 04:51:49AM +, Paul Wise wrote: > Is there any documentation and diagrams on the typical request flows > between the browser the servers involved that happens with OIDC? > Is there an OIDC demo site somewhere so that I can see the requests > between the browser and the servers involved and see which browser > features OIDC uses and requires in practice? My goal in this discussion is to see if there are blockers for moving in the direction that me and Waldi proposed, or to discover unexpected ways in which what we propose would make the situation worse than it is now. I would like to keep this discussion focused on ACK/NACK, so that me and waldi and whoever may want to join the work, can go ahead and start putting together implementation schedule and get things moving. Are your questions an expression of curiosity about the OIDC protocol, or about hinting that there is something there that you consider a blocker to be discussed before we start working? > > However, I don't know how a moderation workflow should work. > > I'd like to see this happen via a "welcome" team. You register an > account with a paragraph about why you're signing up, your account > gets moderated and you receive a welcome email from the team with tips > related to your signup paragraph and to the service where you started > the registration flow, for eg people starting their registration on > the wiki might get a link to the wiki editor guide. > > https://wiki.debian.org/Welcome I would definitely like to see the Welcome Team take off, and I would prefer not to derail what seems like a workable plan about improving the broken Single Sign-On situation, into a discussion about a Debian Welcome Team. I'd love to have a healty, active, and pervasive Welcome Team, and maybe Salsa's an excellent opportunity for Welcome Team contributions. Unless you think having a functional Welcome Team onboard should be considered a blocker for moving on with SSO improvements, could we postpone this to a later point? I'd like to keep this round of discussion focused on two points: - is the current situation broken? - with this proposal, does it become less broken? That the current situation is broken seems to be generally agreed. I haven't yet seen anything that convinced me that what we are proposing would make it more broken, or would prevent further opportunities for moving on. If no serious blockers show up, in a few days I would start to go ahead. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
