Re: Salsa as authentication provider for Debian
On Tue, Apr 7, 2020 at 6:23 PM Bastian Blank wrote: > No, not really. The services ask the SSO service for the identity of > the user and get an attestation back. So each service needs to handle > it's own login. Hmm, the OIDC documentation I've been able to find seemed to indicate the login request on a service gets redirected to the OIDC provider, which then redirects back to the service. Is there any documentation and diagrams on the typical request flows between the browser the servers involved that happens with OIDC? Is there an OIDC demo site somewhere so that I can see the requests between the browser and the servers involved and see which browser features OIDC uses and requires in practice? > However, I don't know how a moderation workflow should work. I'd like to see this happen via a "welcome" team. You register an account with a paragraph about why you're signing up, your account gets moderated and you receive a welcome email from the team with tips related to your signup paragraph and to the service where you started the registration flow, for eg people starting their registration on the wiki might get a link to the wiki editor guide. https://wiki.debian.org/Welcome > How many new users per day do you get? Usually one or two users per day to moderate between Steve and myself, sometimes more, especially during events. Our setup is less optimal for people who don't have email addresses or read errors so there are probably some who aren't contacting us to get an account. Also, to reduce friction for existing FLOSS folks we have a list of related email domains that do not need prior approval. Do we know which other FLOSS related groups Debian's OIDC setup could leverage for additional context at initial account creation? Or are we thinking that we would use email, GitHub, GitLab, Twitter, Facebook etc for that? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Salsa as authentication provider for Debian
Hi Paul On Tue, Apr 07, 2020 at 03:20:52PM +, Paul Wise wrote: > It sounds like the answer is no, but does Salsa, Keycloak or > LemonLDAP::NG support TLS client certs? No, Salsa does not support TLS client certs. > So it sounds like Debian would be switching our SSO authentication > protocol from TLS client certs directly supported by TLS clients to > something based on HTTP redirects, referrers and cookies and that > requires a browser in order to login? Using a browser is the primary method for login with OIDC, yes. > It seems like one side effect of the protocol change is that login > events are centralised on the SSO service rather than at each > individual service. No, not really. The services ask the SSO service for the identity of the user and get an attestation back. So each service needs to handle it's own login. > Is there anything else that account holders need to be aware of? No. > > - nm.debian.org uses Salsa usernames by default to populate LDAP usernames > > when > > creating accounts, and stores OIDC subject to strongly correlate between > > Salsa and Debian LDAP users. > Is it intended that service maintainers each implement OpenID Connect > etc within their service code using existing libraries, or should we > use something like the mod_auth_openidc Apache module to pass > authentication details to service code. > https://github.com/zmartzone/mod_auth_openidc This is up to the service maintainers. I for example use https://github.com/oauth2-proxy/oauth2-proxy > Can services using non-HTTP protocols be authenticated with OpenID Connect > etc? In theory yes. Dovecot for example supports this. > Is it intended that there be moderation at account creation time? In > our experience with the Debian wiki, a large amount of spammers > attempt to sign up. I hear that Salsa gets a lot of spammers signing > up too and those are manually cleaned up if they do something spammy. Currently moderation is not planned. What we might do is forcing new users to be marked as external, which disallows them to do anything. However, I don't know how a moderation workflow should work. Currently the homegrown self-service thingy makes automatic signup unlikely, but this will go away. Salsa itself is also a pretty small target, as almost all content is exempted from indexing. And cleaning up is pretty easy. The only types of spam we had was - snippets in vietnamese and - issues in vietnamese. > One very nice aspect of the wiki signup > moderation is that the team can respond to aspects of the signup > email, welcoming the applicant with pointers to documentation, > suggestions of ideas on how to help, mailing lists to join and so on. How many new users per day do you get? > Is there anything else that service admins need to be aware of? Yes. Please don't use the username (the field is called "nickname"), but only the subject (the field is called "sub") to identify users. Regards, Bastian -- First study the enemy. Seek weakness. -- Romulan Commander, "Balance of Terror", stardate 1709.2
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 03:20:52PM +, Paul Wise wrote: > I'd like to learn a bit about what the effects for Debian account > holders and service admins will be. Thanks, I'll answer where I can. I understand that you're exploring all possible corner cases that might change and we might have to document or generally be aware of, and are not implying that any change in the areas you explore should be considered blockers for migrations away from the status quo. > > - Salsa becomes primary source of user info and authentication for secondary > > services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing > > sso.debian.org. > > It sounds like the answer is no, but does Salsa, Keycloak or > LemonLDAP::NG support TLS client certs? At least as a transition period, I intend to add OIDC authentication to sso.debian.org via libapache2-mod-auth-openidc or something equivalent, so that services that haven't migrated to OIDC can keep working. I guess the same can be done authenticating against Keycloak, LLNG, or most other things we might end up using, although I hope that if sso.debian.org ends up not being needed, we can turn it off after transitions have transitioned: I'm a big fan of reducing the amount of custom code that I have to maintain. > So it sounds like Debian would be switching our SSO authentication > protocol from TLS client certs directly supported by TLS clients to > something based on HTTP redirects, referrers and cookies and that > requires a browser in order to login? Technically yes. Practically, things like OIDC are standard setups, and there are standard ways to deal with non-browser access, like API keys. nm.debian.org for example already supports API keys without the need of a client certificate. > Is it intended that service maintainers each implement OpenID Connect > etc within their service code using existing libraries, or should we > use something like the mod_auth_openidc Apache module to pass > authentication details to service code. > > https://github.com/zmartzone/mod_auth_openidc I suppose each service can choose as they see fit. The apache module would provide a handy migration strategy from the current sso, keeping things handled at the web server level. Each service can decide what to do according to what options are provided by their underlying frameworks: OIDC is a widely supported and adopted standard, and it could be that using the corresponding functionality of Django or whatever framework one has, turns out to be easier for development and maintenance than the web server module. Both options would be available, anyway. If we really find out that we need a CA issuing client certs for some kinds of services, we can still keep maintaining sso.debian.org: it's a simple enough codebase and I think most people would be able to pick it up and maintain it as a CA service for our SSO federation. Note that I'm not aware of anything using sso.debian.org certificates outside a browser. I wrote and published example code to do that years ago, and haven't seen any adoption or even feedback. > Can services using non-HTTP protocols be authenticated with OpenID Connect > etc? > > Is it intended that there be moderation at account creation time? In > our experience with the Debian wiki, a large amount of spammers > attempt to sign up. I hear that Salsa gets a lot of spammers signing > up too and those are manually cleaned up if they do something spammy. > For the wiki we found the best way to prevent spammers from signing up > is human moderation. Even that doesn't always help as I've let > spammers sign up before based on the content of their signup emails, > but it is a good start. One very nice aspect of the wiki signup > moderation is that the team can respond to aspects of the signup > email, welcoming the applicant with pointers to documentation, > suggestions of ideas on how to help, mailing lists to join and so on. I defer to Salsa people for this part. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
> "Xavier" == Xavier writes: Xavier> Le 07/04/2020 à 17:20, Paul Wise a écrit : >> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote: >> >>> ## Highlevel plan >> >> I'd like to learn a bit about what the effects for Debian account >> holders and service admins will be. >> >>> - Salsa becomes primary source of user info and authentication >>> for secondary services via OpenID Connect (OAuth2), for both DDs >>> and non-DDs, replacing sso.debian.org. >> >> It sounds like the answer is no, but does Salsa, Keycloak or >> LemonLDAP::NG support TLS client certs? Xavier> LLNG and KeyCloack support TLS authentication, 2FA,... See Xavier> https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases Xavier> for a complete list of LLNG supported authentication Xavier> mechanisms I authenticate using TLS to the SSO server. But then I use http redirects or JSON tokens to authenticate to the protected app, right? llng does not end up being a short-lived CA like the current sso.debian.org
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 17:20, Paul Wise a écrit : > On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote: > >> ## Highlevel plan > > I'd like to learn a bit about what the effects for Debian account > holders and service admins will be. > >> - Salsa becomes primary source of user info and authentication for secondary >> services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing >> sso.debian.org. > > It sounds like the answer is no, but does Salsa, Keycloak or > LemonLDAP::NG support TLS client certs? LLNG and KeyCloack support TLS authentication, 2FA,... See https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases for a complete list of LLNG supported authentication mechanisms > So it sounds like Debian would be switching our SSO authentication > protocol from TLS client certs directly supported by TLS clients to > something based on HTTP redirects, referrers and cookies and that > requires a browser in order to login? Authentication gives an "authenticationLevel". You can restrict some applications to TLS, some other to "password+2FA or TLS" and authorize some other to use simple authentication > It seems like one side effect of the protocol change is that login > events are centralised on the SSO service rather than at each > individual service. > > Is there anything else that account holders need to be aware of? > >> - nm.debian.org uses Salsa usernames by default to populate LDAP usernames >> when >> creating accounts, and stores OIDC subject to strongly correlate between >> Salsa and Debian LDAP users. Application profiles can be managed by SSO (give profile to app and/or restrict some URL to a particular group [handler/GateKeeper only]) > Is it intended that service maintainers each implement OpenID Connect > etc within their service code using existing libraries, or should we > use something like the mod_auth_openidc Apache module to pass > authentication details to service code. Both are possible but handler/GateKeeper can do the job > https://github.com/zmartzone/mod_auth_openidc > > Can services using non-HTTP protocols be authenticated with OpenID Connect > etc? > > Is it intended that there be moderation at account creation time? In > our experience with the Debian wiki, a large amount of spammers > attempt to sign up. I hear that Salsa gets a lot of spammers signing > up too and those are manually cleaned up if they do something spammy. Yes, possible > For the wiki we found the best way to prevent spammers from signing up > is human moderation. Even that doesn't always help as I've let > spammers sign up before based on the content of their signup emails, > but it is a good start. One very nice aspect of the wiki signup > moderation is that the team can respond to aspects of the signup > email, welcoming the applicant with pointers to documentation, > suggestions of ideas on how to help, mailing lists to join and so on. > > Is there anything else that service admins need to be aware of?
Re: Salsa as authentication provider for Debian
On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote: > ## Highlevel plan I'd like to learn a bit about what the effects for Debian account holders and service admins will be. > - Salsa becomes primary source of user info and authentication for secondary > services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing > sso.debian.org. It sounds like the answer is no, but does Salsa, Keycloak or LemonLDAP::NG support TLS client certs? So it sounds like Debian would be switching our SSO authentication protocol from TLS client certs directly supported by TLS clients to something based on HTTP redirects, referrers and cookies and that requires a browser in order to login? It seems like one side effect of the protocol change is that login events are centralised on the SSO service rather than at each individual service. Is there anything else that account holders need to be aware of? > - nm.debian.org uses Salsa usernames by default to populate LDAP usernames > when > creating accounts, and stores OIDC subject to strongly correlate between > Salsa and Debian LDAP users. Is it intended that service maintainers each implement OpenID Connect etc within their service code using existing libraries, or should we use something like the mod_auth_openidc Apache module to pass authentication details to service code. https://github.com/zmartzone/mod_auth_openidc Can services using non-HTTP protocols be authenticated with OpenID Connect etc? Is it intended that there be moderation at account creation time? In our experience with the Debian wiki, a large amount of spammers attempt to sign up. I hear that Salsa gets a lot of spammers signing up too and those are manually cleaned up if they do something spammy. For the wiki we found the best way to prevent spammers from signing up is human moderation. Even that doesn't always help as I've let spammers sign up before based on the content of their signup emails, but it is a good start. One very nice aspect of the wiki signup moderation is that the team can respond to aspects of the signup email, welcoming the applicant with pointers to documentation, suggestions of ideas on how to help, mailing lists to join and so on. Is there anything else that service admins need to be aware of? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 09:14:11AM -0500, Michael Lustfield wrote: > I can very much appreciate a desire to get a replacement rolled out as quickly > as possible. The more I learn about the current situation [1], the more > alarming > it is. However, please don't consider the work Lucas and I are doing as > stalling. I was unaware that the whole effort stalled. I'm currently between > contracts and have plenty of free time to make something happen. > > I also like to think of a myself as a good masochist. You can expect me to > stick around for the long term. :) That's great, and I also don't want the Salsa improvement we proposed to be a blocker for further developments. As far as I'm concerned, we could get started with migrating services to OIDC consumers[1], unblocking new non-DD access to services, and cleaning up the status quo a bit. Sooner or later, your and Luca's work (or somebody else's, or all of them) can get validated, and can pick it the situation from where we left it and keep improving. [1] or even simply libapache2-mod-auth-openidc, since the current cert system is handled by apache anyway > Aside from the security concern I raised earlier, it's largely a "gut feeling" > that comes from seeing how quickly legacy quirks develop in any new > deployment. > If Salsa needs to make any assumption or enforcements that Alioth did not, > those will need to be accounted for in the new solution. Additionally, we > already have a clean path I don't understand what you mean with "any assumption of enforcements". > Something that comes to mind is what it would take to migrate accounts from > Salsa to somewhere else. Does gitlab provide user exports? As unfortunate as > it > is that alioth's DB is now a flat-file managed by hand, it provides a very > simple and easy way to import all of that data. Gitlab does indeed provide user exports: some more details are in the "Exit strategy" part of the proposal Waldi posted. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Tue, 7 Apr 2020 13:50:06 +0200 Enrico Zini wrote: > On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > > I would like to avoid stalling progress on sso on things like analysis > paralysis, or like sorting out deployment details, as happened in the > last years. I can very much appreciate a desire to get a replacement rolled out as quickly as possible. The more I learn about the current situation [1], the more alarming it is. However, please don't consider the work Lucas and I are doing as stalling. I was unaware that the whole effort stalled. I'm currently between contracts and have plenty of free time to make something happen. I also like to think of a myself as a good masochist. You can expect me to stick around for the long term. :) [1] oh my... https://wiki.debian.org/DebianSingleSignOn#If_you_ARE_NOT_.28yet.29_a_Debian_Developer > I'll ask you the same question I asked Luca: is there something in the > Salsa proposal that would prevent further experimentation with LLNG and > eventually possibly integrating it into the ecosystem, or migrating to > it? Aside from the security concern I raised earlier, it's largely a "gut feeling" that comes from seeing how quickly legacy quirks develop in any new deployment. If Salsa needs to make any assumption or enforcements that Alioth did not, those will need to be accounted for in the new solution. Additionally, we already have a clean path Something that comes to mind is what it would take to migrate accounts from Salsa to somewhere else. Does gitlab provide user exports? As unfortunate as it is that alioth's DB is now a flat-file managed by hand, it provides a very simple and easy way to import all of that data. > [...] > As a side effect of an interim on Salsa, services can begin to migrate > from client certificates to OIDC, switching to a mode widely used, > usable, and flexible standard, which I wouldn't be surprised if it would > make things easier when moving to something else later on. If there aren't any practical issues with migrating away from salsa in the future, then I wouldn't have any objection, but the voice in the back of my head is screaming pretty loudly right now. -- Michael Lustfield
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 16:02, Enrico Zini a écrit : > On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote: > >> With a SSO, I don't think it's a good thing to have a protected app as >> user database (even if it's possible). Then migration consists to >> extract gitlab accounts and push them in LDAP (2 branches, one for DD, >> one for guests) > > Ok, please help me to see where that would be an issue. It's not an issue. With a SSO we shall probably change this: salsa accounts will be created on-the-fly using federation mechanism, then there is only one user database (LDAP with 2 branches) > The current status of accounts, is that: > > - There is only one LDAP server, DSA-managed, on db.debian.org, which >has accounts that do not end in "-guest". They may be DD or ex-DD >accounts, or "guest accounts" created for non-DDs who need to have >temporary access to porterboxes > > - There are accounts ending in "-guest" (that are not "guest >accounts"), that are not managed by DSA, and used to be on Alioth's >separate LDAP when alioth existed. > > - "-guest" accounts for purposes on sso.debian.org authentication are >now stored on a hand-maintained text file that is exported somehow to >serve as an apache authentication source for sso.debian.org > > - "-guest" accounts on Salsa are stored on Salsa's user database > > We currently have all sorts of overlaps and corner cases: > > - "guest accounts" in LDAP that do not end in "-guest" and are for >non-DDs > - "-guest" accounts in Salsa for DDs and ex-DDs, with the part before >"-guest" not matching the LDAP account name. > > I wonder if we have the same "-guest" accounts in Salsa and in the > sso.debian.org text file, that are controlled by different people? > > With the Salsa proposal: > > - the text file disappears, reducing the count of user databases from 3 >to 2 > - LDAP remains as it is, and Salsa remains as it is > - DD accounts remain on LDAP > - We gain an explicit mapping between LDAP accounts and Salsa accounts, >via nm.debian.org, that we currently do not have > - People who gain or lose DD status can keep using their Salsa account >without needing to migrate from "something-guest" to "something", or >from "something" to "something-guest" > > With the Salsa proposal the only change from here that I can see is that > we would start to have non-DD accounts on Salsa that do not end with > "-guest", like we already have non-DD accounts on LDAP now that do not > end with "-guest". > > I still don't see how the Salsa proposal makes adoption of a new system > harder than what we have now: removing one user database and introducing > a mapping between the remaining two, seem to me to make further > adoptions actually easier. No not harder, just different ;-)
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote: > With a SSO, I don't think it's a good thing to have a protected app as > user database (even if it's possible). Then migration consists to > extract gitlab accounts and push them in LDAP (2 branches, one for DD, > one for guests) Ok, please help me to see where that would be an issue. The current status of accounts, is that: - There is only one LDAP server, DSA-managed, on db.debian.org, which has accounts that do not end in "-guest". They may be DD or ex-DD accounts, or "guest accounts" created for non-DDs who need to have temporary access to porterboxes - There are accounts ending in "-guest" (that are not "guest accounts"), that are not managed by DSA, and used to be on Alioth's separate LDAP when alioth existed. - "-guest" accounts for purposes on sso.debian.org authentication are now stored on a hand-maintained text file that is exported somehow to serve as an apache authentication source for sso.debian.org - "-guest" accounts on Salsa are stored on Salsa's user database We currently have all sorts of overlaps and corner cases: - "guest accounts" in LDAP that do not end in "-guest" and are for non-DDs - "-guest" accounts in Salsa for DDs and ex-DDs, with the part before "-guest" not matching the LDAP account name. I wonder if we have the same "-guest" accounts in Salsa and in the sso.debian.org text file, that are controlled by different people? With the Salsa proposal: - the text file disappears, reducing the count of user databases from 3 to 2 - LDAP remains as it is, and Salsa remains as it is - DD accounts remain on LDAP - We gain an explicit mapping between LDAP accounts and Salsa accounts, via nm.debian.org, that we currently do not have - People who gain or lose DD status can keep using their Salsa account without needing to migrate from "something-guest" to "something", or from "something" to "something-guest" With the Salsa proposal the only change from here that I can see is that we would start to have non-DD accounts on Salsa that do not end with "-guest", like we already have non-DD accounts on LDAP now that do not end with "-guest". I still don't see how the Salsa proposal makes adoption of a new system harder than what we have now: removing one user database and introducing a mapping between the remaining two, seem to me to make further adoptions actually easier. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 14:38, Enrico Zini a écrit : > On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote: > >>> I'll ask you the same question I asked Luca: is there something in the >>> Salsa proposal that would prevent further experimentation with LLNG and >>> eventually possibly integrating it into the ecosystem, or migrating to >>> it? >> >> No, just to migrate accounts > > Could you give some more detail of what you mean? With a SSO, I don't think it's a good thing to have a protected app as user database (even if it's possible). Then migration consists to extract gitlab accounts and push them in LDAP (2 branches, one for DD, one for guests)
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote: > > I'll ask you the same question I asked Luca: is there something in the > > Salsa proposal that would prevent further experimentation with LLNG and > > eventually possibly integrating it into the ecosystem, or migrating to > > it? > > No, just to migrate accounts Could you give some more detail of what you mean? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 13:50, Enrico Zini a écrit : > On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > >> Resume of proposition: >> * all users managed by SSO; self-registration authorized with "-guest" >>in a distinct LDAP branch >> * GitLab becomes a slave of SSO using SAML (or OIDC) >> * other applications are protected by handlers/GateKeepers. If LLNG is >>chosen, just to add few lines in Nginx configuration >> * new applications can be protected using handlers, SAML, CAS, OIDC,... >> >> > > I greatly appreciate yours and Luca's and Michael's proposals, and > offers of help. Thanks ! > I would like to avoid stalling progress on sso on things like analysis > paralysis, or like sorting out deployment details, as happened in the > last years. > > I'll ask you the same question I asked Luca: is there something in the > Salsa proposal that would prevent further experimentation with LLNG and > eventually possibly integrating it into the ecosystem, or migrating to > it? No, just to migrate accounts > If not, then we could start with that, which requires no deployment of > new software, and on which we can make progress immediately, and buy > time for everyone to work out the perfect solution, meanwhile moving on > from an unsustainable status quo. > > As a side effect of an interim on Salsa, services can begin to migrate > from client certificates to OIDC, switching to a mode widely used, > usable, and flexible standard, which I wouldn't be surprised if it would > make things easier when moving to something else later on. > > Enrico Little addon: LLNG has a GPG auth plugin, this can be useful to self-reinitialize lost passwords or unlock accounts if password policy blocks it and/or register new DDs
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > Resume of proposition: > * all users managed by SSO; self-registration authorized with "-guest" >in a distinct LDAP branch > * GitLab becomes a slave of SSO using SAML (or OIDC) > * other applications are protected by handlers/GateKeepers. If LLNG is >chosen, just to add few lines in Nginx configuration > * new applications can be protected using handlers, SAML, CAS, OIDC,... > > I greatly appreciate yours and Luca's and Michael's proposals, and offers of help. I would like to avoid stalling progress on sso on things like analysis paralysis, or like sorting out deployment details, as happened in the last years. I'll ask you the same question I asked Luca: is there something in the Salsa proposal that would prevent further experimentation with LLNG and eventually possibly integrating it into the ecosystem, or migrating to it? If not, then we could start with that, which requires no deployment of new software, and on which we can make progress immediately, and buy time for everyone to work out the perfect solution, meanwhile moving on from an unsustainable status quo. As a side effect of an interim on Salsa, services can begin to migrate from client certificates to OIDC, switching to a mode widely used, usable, and flexible standard, which I wouldn't be surprised if it would make things easier when moving to something else later on. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
Le 05/04/2020 à 20:46, Bastian Blank a écrit : > Dear Debian fellows > > Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the > following plan. At the same time we declare the following services as EOL: > - sso.debian.org and > - parts of the Salsa self service interface. > > We asked DPL, NM, DSA and the Salsa admins already for feedback about what we > intend to do. > > We mostly got positive feedback from them, with some reservations about the > user renames. > > We did not receive a response from DSA to date. We only got some personal > remarks from jcristau and weasel on IRC. They don't want to handle Salsa > differently and store information. Also they declared worry about user name > conflicts. > > We did some changes to remedy those, so we scrapped the changes we had asked > DSA to do and will check for name conflicts in nm.debian.org before sending > user creation requests to DSA. > > Regards, > Enrico and Bastian Hi, I can help if you want to use lemondap-ng (LLNG: https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng) > ## Current state > > - We have multiple user sources: > - Debian LDAP, > - Salsa (which syncs DD from Debian LDAP) and > - "Alioth" guest "LDAP" for sso.debian.org. LLNG can handle multiple sources (2 modules for that: user choice or automatic calculation using combination module) > - We have no way to rename users, neither within the Debian LDAP, nor Salsa. > Renames require a complete new user. > - A person transitioning between non-DD and DD needs a new user and loses all > state. > - Guest users on Salsa are forced to end with `-guest`. > > ## Highlevel plan > > - Salsa becomes primary source of user info and authentication for secondary > services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing > sso.debian.org. This requires to change all services. Using a SSO is easier here: gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app without having to change to many things. LLNG handlers are directly included in Apache/Nginx configuration and provides HTTP-headers to the web app. Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal then becomes transparent > - Salsa allows user renames and drops namespace rules for users (i.e., no more > requirement for -guest suffix). > - nm.debian.org uses Salsa usernames by default to populate LDAP usernames > when > creating accounts, and stores OIDC subject to strongly correlate between > Salsa and Debian LDAP users. > > ## Fixed problems > > - We get a user source everyone can use both as service provider and user. > - Users can rename themselves before becoming DDs, and retain all information > both on Salsa and on other services. This also works while transitioning > between non-DD and DD, and back. > > ## Corner cases > > The Salsa and LDAP databases don't need to be in sync: > > - The interaction between the two namespaces only happens when the Salsa > namespace provides the value for a new DD's LDAP UID. By using salsa as > default for LDAP UID, we keep the names roughly in sync for convenience > - Conflicts can happen when a prospective new DD has a Salsa username that > corresponds to an already allocated LDAP uid, and they can be detected and > handled on nm.debian.org before account creation: people can be told that > their salsa username is already in use in LDAP, and get a chance to rename > it. > - If one renames their Salsa account after becoming DD, someone else could > start using the old name and exploit the confusion. This would be a rare > occurrence, and Salsa admins can lock the malicious account if that happens. > > People can rename their account on Salsa even after the account exists in > LDAP, > since the OIDC identifying information would be the subject, which is the > GitLab internal user ID, which is preserved across renames. > > nm.debian.org will provide official membership information to Salsa, so the > Debian group on Salsa will remain, showing DD status. > > ## Required changes > > ### Salsa > > - Enable sign-on and allow user rename (last step). > - Remove user support from Salsa self service interface. > > ### Salsa user sync > > - Use nm.debian.org as data source for official DD status. > - Add/remove @debian.org e-mail addresses in user information, from > nm.debian.org > > ### nm.debian.org > > - Support OIDC to get subject, username, display name and e-mail address for > users. > - Supply information about DD for consumption by Salsa user sync. > - Check for username conflicts. > > ### sso.debian.org > > - Authenticate via OIDC to provide certificate management for a transition > period, until all sso-using services have migrated to OIDC > > ## Exit plan > > Should GitLab and/or Salsa become unmaintainable, what do we need to migrate > away? It's easy to
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote: > On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote: > > > > I don't know keycloak: what are the maintenance costs, and what would be > > > the benefits over time? > > > > > > Right now, with the proposal waldi just posted, we have very little to > > > no added maintenance cost, possibly negative maintenance cost once we > > > take sso.debian.org and the current handcrafted salsa subscription thing > > > offline. The amount of code deployed compared to the status quo would go > > > *down*. The user interface and user experience for the lot would be good > > > and well known. Gitlab's codebase, while large and complex, is widely > > > deployed, and we already have know-how about it in Debian. > > > > Having just joined this conversation, the above is an argument that is > > difficult to refute: one can always argue that 'one in the hand is > > better than one in the bush'. > > Yes :/ I think that's more or less where we are now, unfortunately, > after a year or more failing to find people to deploy and maintain > alternatives. > > On one hand, client certificate handling in browsers gets worse over > time, and the current sso solution is effectively running on people > collecting all sorts of workaround instructions in the excellent wiki > page at https://wiki.debian.org/DebianSingleSignOn > > On the other hand, signing in for non-DDs is a major hurdle that takes > literally weeks, when one can find out how to do it at all. We DDs care > little about that, it's Not Our Problem. That barrier makes joining > nm.debian.org to become a DD a challenge in itself. Other things like > managing one's own information on contributors.debian.org are just not > worth the challenge, and I'm planning to take contributors.d.o offline > soon, because I/we can't, ethically and legally, publish people's > information without giving those people a reasonable chance to control > it. > > > > My DSA colleagues asked for demo and I'm building that up, currently. I > > view this as a positive but not definitive step in the maintenance > > questions. > > > > I appreciate that the idea of using keycloak as an IdB requires everyone > > to shift perspective. > > > > Let me know if you have appetite (or not*) to discuss the above. > > Personally I'm interested in anything that works and that I can have a > very good confidence that somebody will maintain over time. > > I care about maintenance and sustainability more than about anything > else, because I'm the one who's been forced to set up and maintain SSO > in Debian mostly alone for 8 years, because everybody else walked away > from it and I could not. > > OIDC supports various authentication sources, and the Salsa plan > decouples OIDC from LDAP allowing them to evolve independently, removes > custom nonstandard components, and includes the option of migrating away > to something else in the future. In my understanding it enables > experimentation with other systems rather than blocking it. > > Question: is there something in the proposed Salsa plan that somehow > blocks experimenting with, introducing, or migrating to Keycloak in the > future? Euh there is | What does keycloak provide over something like lemonldap or similar tools? elsewhere in this thread. So I take the liberty to change one question It there something in the proposed Salsa plan that somehow blocks experimenting with, introducing, or migrating to an identity provider in the future? Regards Geert Stappers -- Silence is hard to parse
Re: Salsa as authentication provider for Debian
On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote: > > I don't know keycloak: what are the maintenance costs, and what would be > > the benefits over time? > > > > Right now, with the proposal waldi just posted, we have very little to > > no added maintenance cost, possibly negative maintenance cost once we > > take sso.debian.org and the current handcrafted salsa subscription thing > > offline. The amount of code deployed compared to the status quo would go > > *down*. The user interface and user experience for the lot would be good > > and well known. Gitlab's codebase, while large and complex, is widely > > deployed, and we already have know-how about it in Debian. > > Having just joined this conversation, the above is an argument that is > difficult to refute: one can always argue that 'one in the hand is > better than one in the bush'. Yes :/ I think that's more or less where we are now, unfortunately, after a year or more failing to find people to deploy and maintain alternatives. On one hand, client certificate handling in browsers gets worse over time, and the current sso solution is effectively running on people collecting all sorts of workaround instructions in the excellent wiki page at https://wiki.debian.org/DebianSingleSignOn On the other hand, signing in for non-DDs is a major hurdle that takes literally weeks, when one can find out how to do it at all. We DDs care little about that, it's Not Our Problem. That barrier makes joining nm.debian.org to become a DD a challenge in itself. Other things like managing one's own information on contributors.debian.org are just not worth the challenge, and I'm planning to take contributors.d.o offline soon, because I/we can't, ethically and legally, publish people's information without giving those people a reasonable chance to control it. > My DSA colleagues asked for demo and I'm building that up, currently. I > view this as a positive but not definitive step in the maintenance > questions. > > I appreciate that the idea of using keycloak as an IdB requires everyone > to shift perspective. > > Let me know if you have appetite (or not*) to discuss the above. Personally I'm interested in anything that works and that I can have a very good confidence that somebody will maintain over time. I care about maintenance and sustainability more than about anything else, because I'm the one who's been forced to set up and maintain SSO in Debian mostly alone for 8 years, because everybody else walked away from it and I could not. OIDC supports various authentication sources, and the Salsa plan decouples OIDC from LDAP allowing them to evolve independently, removes custom nonstandard components, and includes the option of migrating away to something else in the future. In my understanding it enables experimentation with other systems rather than blocking it. Question: is there something in the proposed Salsa plan that somehow blocks experimenting with, introducing, or migrating to Keycloak in the future? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
Hi Luca On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote: > That said, please consider an approach that would see keycloak used as > an idenitity broker, allowing external users to create accounts using > social identities that are then promoted to full Debian identities (in > LDAP) if they complete the onboarding process. You are proposing a different idea, however you are not yet proposing a project with actionable items on it. If you think this is worthwhile, please provide at least the following things: - Workflows, esp non-DD to DD and vice versa. - Self service, e.g. user signup, how do users add OIDC clients, how add groups/roles to OIDC info. - Salsa, how should it work together. - Additional features - Who is willing to maintain this long-term - Exit strategy Anyway, I took a quick look into Keycloak. What I find particular interesting is: - they use UUID for user identification - users and groups can have arbitrary attributes attached to them, however they are not self service - it is a complete authorization solution What isn't so great - no particular good admin interface (there are 40+ settings for each OIDC client alone) - it can have forms without a required field, which can't be saved at all. - jboss. Who considers itself capable of running public jboss applications safely and securely? Showstopper - no self service for group or even OIDC clients - no U2F (okay, GitLab also still needs to make the step to webauthn) - requires Java 8, which is not supported on Debian Buster I was not able to see the killer feature of this setup or at least one feature that we must have. >Could be used as > replacement for debsso, could be used for wiki, could be used for > debconf, could be used for salsa. But this is not different to what we already proposed. Also all the other modifications we need to do to for example Salsa and NM are already the same. Regards, Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
