On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline <jeremy@xxxxxxxxxx> wrote: > > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > > > > > Good Morning, > > > > > > We posted this [1] blog today and want to open a mailing thread to garner > > > feedback, field questions and get some thoughts from the Community on > > > the approach that we in Community Platform Engineering (CPE) are taking. > > > > > > [1] https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ > > > > > > > Two things that concern me at this time: > > <snip> > > > > > > Ipsilon — Ipsilon is our identity provider. It supports multiple > > > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …) > > > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system accounts…). > > > While it was originally shipped as a tech preview in RHEL it no longer is and > > > the team working on this application has also been refocused on other projects. > > > We would like to move all our applications to use OpenID Connect or SAML 2.0 > > > (instead of OpenID 2.0 with (custom) extensions) and replace FAS with an > > > IPA-based solution, which in turn allows us to replace ipsilon by a more > > > maintained solution, likely Red Hat Single Sign On. The dependencies > > > are making this a long term effort. We will need to announce to the community > > > that this means we will shut down the public OpenID 2.0 endpoints, > > > which means that any community services that use this protocol need > > > to be moved to OpenID Connect as well. > > > > There are two issues to unpack here: > > > > 1. We use a weird custom backend and custom protocol extensions. > > > > This should definitely be replaced if it makes sense. It’s more urgent > > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python > > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS > > developers died a while ago… > > > > Naturally, the replacement is equally in a poor state, but may have > > some legs someday: https://github.com/fedora-infra/noggin > > > > 2. Ipsilon development was only considered important as part of being > > tech preview in RHEL and now it’s not. > > > > There are some major problems here. First of all, Ipsilon development > > has been gated by a single person. That person also seems to have > > trouble making time to review pull requests. There has been interest > > from the broader community about using and contributing to Ipsilon, > > since unlike Keycloak, it is written in an accessible language > > (Python). > > > > Getting Ipsilon to Python 3 would be enough for me to get started on > > bootstrapping some of the other interested parties onto Ipsilon, and > > hopefully give us a more sustainable community long-term. > > I guess my question to all this is... Why? What's the goal? If Keycloak > does everything Ipsilon does and more, what's the point of keeping a > dead project alive instead of contributing to the active, lively one? > > If there really, truly is interest from the broader community, why not > do a friendly fork, get all the work you want in, and see what the > original maintainer thinks? > Keycloak is not generally Fedora contributor friendly. Aside from it being written in Java (which is problematic with the Java stack in Fedora slowly imploding...), Keycloak is a lot less flexible and a lot more tied to aspects of RHEL/Fedora that make it annoying to use in other environments. At least with Ipsilon, the Python codebase makes it easy for a broad base of contributors to hack on the code. It's also much easier to set up than Keycloak and easier to plug into more environments. The biggest issue with Ipsilon as a project is the lack of awareness of its existence. That has allowed the fact that the maintainer hasn't recently been able to focus on it in a while to be unnoticed. Now that is changing, and this is a problem, as I outline later... > For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace > Pagure, or a generic notification service exists somewhere to replace > FMN, or whatever, why spend time on such things we could be spending > developing the few unique tools we need to continue building the Fedora > distribution? Stopping along the way to build an identity and access > management platform isn't going to make the distribution better. > FreeIPA is a perfectly fine solution, since it's broadly available and easy to deploy. The non-Java parts (everything but Dogtag) is quite easy to understand and hack on. Reproducing the tooling and environment is easy as well. I have no problems with it other than FAS-specific functions still need implementing on top of FreeIPA (which in theory, Noggin will do). It's more complicated than I'd like in some ways, but at least setup is replicable, making it easy to do development and contribute. As for GitLab vs Pagure, my reasoning is more or less than same as mine with Keycloak vs Ipsilon. And there *are* users other than us for both Pagure and Ipsilon. The difference between Ipsilon and Pagure, in my view, is the primary maintainer. Pierre-Yves Chibon has been very accessible and a pleasure to work with as part of contributing to Pagure. I have virtually no experience interacting with Patrick Uiterwijk because he's barely around. We have a number of projects that we're basically said only the "security guy" can work on (i.e. Patrick). That's more of a problem than anything else the CPE team does. The bus factor of *one* security person is ridiculous, and the fact we're stretching him across both CentOS and Fedora now means he doesn't pay enough attention to either project. If we're going to have this (frankly insane) requirement that we need to block all this on a security person, we need more than one. Full stop. And you know what? Projects like FAS, Ipsilon, and Pagure *do* make Fedora better in my eyes. With the exception of modularity, we haven't built solutions that are so obscenely complicated that no one can reasonably set up to replicate our environment. All the other solutions out there are immensely more complicated, focusing on things we don't care about, and generally being a pain for normal people to get access to, deploy, modify, and contribute to. I don't understand why this is something that is so easily forgotten... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
