Re: Salsa as authentication provider for Debian
On Mon, 6 Apr 2020 20:38:59 +0200 Enrico Zini 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. Could be used as > > replacement for debsso, could be used for wiki, could be used for > > debconf, could be used for salsa. What does keycloak provide over something like lemonldap or similar tools? > [...] > and well known. Gitlab's codebase, while large and complex, is widely > deployed, and we already have know-how about it in Debian. I was previously involved with a company that audited various git-hosting services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so please forgive the lack of specifics. Gitlab is a tool that gets many things right, and many things wrong. Access control is an area where I have seen some critical bugs. Some of those bugs lead me to not trust it as a non-internal authentication source. Security aside, and perhaps more importantly, is the vendor lock-in problem that can be seen with Alioth. If that system were not being used as an authentication source, then the whole migration would have been entirely agnostic to such concerns and changing auth sources would never have come up. Choosing to migrate to gitlab as an authentication source just introduces a painful(?) migration for the sake of another similar migration in the future. > I would not want to see a workable proposal that we could implement over > the next two weeks and that we have the resources to maintain long-term, > blocked by something that risks getting us stuck with sso.d.o for > another bunch of years until we get it right, and possibly ending up > being maintained long term by a team with a dwindling bandwidth and bus > factor. I was previously (before gitlab's deployment) lead to believe that the problem was already being dealt with. Since this is still a problem, then I volunteer to implement and maintain whatever solution is most appropriate. Is there any summary of where those previous discussions lead and/or their conclusions? I saw something about GSoC mentioned. Is there anything viable which can be taken from that effort? Also, please, don't focus on time to deployment. I'll do whatever we need in order to implement a proper long-term solution. As you may have noticed- I take my time to plan projects before execution. If anything, this is a change that should involve more planning than anything else. -- Michael Lustfield
Re: Salsa as authentication provider for Debian
On Mon, Apr 06, 2020 at 08:38:59PM +0200, Enrico Zini 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. Could be used as > > replacement for debsso, could be used for wiki, could be used for > > debconf, could be used for salsa. > > I don't know keycloak: what are the maintenance costs, and what would be > the benefits over time? > > Right now, with the proposal waldi just posted, we have very little to > no added maintenance cost, possibly negative maintenance cost once we > take sso.debian.org and the current handcrafted salsa subscription thing > offline. The amount of code deployed compared to the status quo would go > *down*. The user interface and user experience for the lot would be good > and well known. Gitlab's codebase, while large and complex, is widely > deployed, and we already have know-how about it in Debian. Having just joined this conversation, the above is an argument that is difficult to refute: one can always argue that 'one in the hand is better than one in the bush'. > I would not want to see a workable proposal that we could implement over > the next two weeks and that we have the resources to maintain long-term, > blocked by something that risks getting us stuck with sso.d.o for > another bunch of years until we get it right, and possibly ending up > being maintained long term by a team with a dwindling bandwidth and bus > factor. Again, I'm just joining this conversation now. Keycloak is a RedHat-sponsored Java-based open-source project that provides a standards-based (SAML and OpenID) Identity Provider (IdP). It can also operate as an Identity Brokder (IdB). As an IdP, it can use an internal data store for users (database) or an external one (LDAP). It has a variety of workflows for user onboarding, user managed access, etc. As an IdB, it can be configured to allow 'social-to-identity' workflows so that users may begin their identity experience using their existing social identies (Gmail, Twitter, etc.). This is in addition to the users from the above IdP for Debian Developers. Service operators (websites, etc.) could then elect to accept all users or to require a role assignment / group membership to grant access to the service. Finally, should a user have started with a social identity but have successfully completed the Applicant process, then there are workflows that would allow users to merge their identities. My DSA colleagues asked for demo and I'm building that up, currently. I view this as a positive but not definitive step in the maintenance questions. I appreciate that the idea of using keycloak as an IdB requires everyone to shift perspective. Let me know if you have appetite (or not*) to discuss the above. Thanks, Luca * If not, then I'll stop advocating for this approach. There's the potential for a heated conversation, here, and I'm not up for that. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
Dear waldi, Enrico, On Sun, Apr 05, 2020 at 08:46:10PM +0200, Bastian Blank wrote: [many many details] yay! many thanks for starting & doing this, this is gonna be awesome! ( & thanks to those helping making this happen as well! Either by action or thoughts.) > ## Exit plan I especially like that you have this in mind already. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
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. Could be used as > replacement for debsso, could be used for wiki, could be used for > debconf, could be used for salsa. I don't know keycloak: what are the maintenance costs, and what would be the benefits over time? Right now, with the proposal waldi just posted, we have very little to no added maintenance cost, possibly negative maintenance cost once we take sso.debian.org and the current handcrafted salsa subscription thing offline. The amount of code deployed compared to the status quo would go *down*. The user interface and user experience for the lot would be good and well known. Gitlab's codebase, while large and complex, is widely deployed, and we already have know-how about it in Debian. I would not want to see a workable proposal that we could implement over the next two weeks and that we have the resources to maintain long-term, blocked by something that risks getting us stuck with sso.d.o for another bunch of years until we get it right, and possibly ending up being maintained long term by a team with a dwindling bandwidth and bus factor. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Sun, Apr 05, 2020 at 08:46:10PM +0200, Bastian Blank wrote: > We did not receive a response from DSA to date. We only got some personal > remarks from jcristau and weasel on IRC. They don't want to handle Salsa > differently and store information. Also they declared worry about user name > conflicts. > > We did some changes to remedy those, so we scrapped the changes we had asked > DSA to do and will check for name conflicts in nm.debian.org before sending > user creation requests to DSA. I think the above mischaracterizes DSA's response and opinion: specifically, there was an engagement with you in #debian-admin on or about April 3rd in response to this topic specifically. That said, please consider an approach that would see keycloak used as an idenitity broker, allowing external users to create accounts using social identities that are then promoted to full Debian identities (in LDAP) if they complete the onboarding process. Could be used as replacement for debsso, could be used for wiki, could be used for debconf, could be used for salsa. Thanks, Luca -- Luca Filipozzi
Salsa as authentication provider for Debian
Dear Debian fellows Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the following plan. At the same time we declare the following services as EOL: - sso.debian.org and - parts of the Salsa self service interface. We asked DPL, NM, DSA and the Salsa admins already for feedback about what we intend to do. We mostly got positive feedback from them, with some reservations about the user renames. We did not receive a response from DSA to date. We only got some personal remarks from jcristau and weasel on IRC. They don't want to handle Salsa differently and store information. Also they declared worry about user name conflicts. We did some changes to remedy those, so we scrapped the changes we had asked DSA to do and will check for name conflicts in nm.debian.org before sending user creation requests to DSA. Regards, Enrico and Bastian ## Current state - We have multiple user sources: - Debian LDAP, - Salsa (which syncs DD from Debian LDAP) and - "Alioth" guest "LDAP" for sso.debian.org. - We have no way to rename users, neither within the Debian LDAP, nor Salsa. Renames require a complete new user. - A person transitioning between non-DD and DD needs a new user and loses all state. - Guest users on Salsa are forced to end with `-guest`. ## Highlevel plan - Salsa becomes primary source of user info and authentication for secondary services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing sso.debian.org. - Salsa allows user renames and drops namespace rules for users (i.e., no more requirement for -guest suffix). - nm.debian.org uses Salsa usernames by default to populate LDAP usernames when creating accounts, and stores OIDC subject to strongly correlate between Salsa and Debian LDAP users. ## Fixed problems - We get a user source everyone can use both as service provider and user. - Users can rename themselves before becoming DDs, and retain all information both on Salsa and on other services. This also works while transitioning between non-DD and DD, and back. ## Corner cases The Salsa and LDAP databases don't need to be in sync: - The interaction between the two namespaces only happens when the Salsa namespace provides the value for a new DD's LDAP UID. By using salsa as default for LDAP UID, we keep the names roughly in sync for convenience - Conflicts can happen when a prospective new DD has a Salsa username that corresponds to an already allocated LDAP uid, and they can be detected and handled on nm.debian.org before account creation: people can be told that their salsa username is already in use in LDAP, and get a chance to rename it. - If one renames their Salsa account after becoming DD, someone else could start using the old name and exploit the confusion. This would be a rare occurrence, and Salsa admins can lock the malicious account if that happens. People can rename their account on Salsa even after the account exists in LDAP, since the OIDC identifying information would be the subject, which is the GitLab internal user ID, which is preserved across renames. nm.debian.org will provide official membership information to Salsa, so the Debian group on Salsa will remain, showing DD status. ## Required changes ### Salsa - Enable sign-on and allow user rename (last step). - Remove user support from Salsa self service interface. ### Salsa user sync - Use nm.debian.org as data source for official DD status. - Add/remove @debian.org e-mail addresses in user information, from nm.debian.org ### nm.debian.org - Support OIDC to get subject, username, display name and e-mail address for users. - Supply information about DD for consumption by Salsa user sync. - Check for username conflicts. ### sso.debian.org - Authenticate via OIDC to provide certificate management for a transition period, until all sso-using services have migrated to OIDC ## Exit plan Should GitLab and/or Salsa become unmaintainable, what do we need to migrate away? We can export username, e-mail addresses, group membership and OIDC subject into a new system. Passwords may not be portable. Most OIDC using services allow multiple authentication providers out of the box, so adding a new authentication system can be straightforward. If replacing Salsa, the issue would be to map user-related information from Salsa's OIDC subject to whatever the new system uses, and data can be exported from Salsa to help creating such mapping lists services can use to transition. -- You canna change the laws of physics, Captain; I've got to have thirty minutes!
