On Tue, Apr 07, 2020 at 03:20:52PM +0000, 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 <enrico@enricozini.org>
Attachment:
signature.asc
Description: PGP signature