Before opening this service broadly to the community, one thing we must agree on is the way we manage authentication and permission.
Let first clarify permission.
Discourse has a specific and very interesting way for open communities to manage permission.
Someone is either a “staff” member or a “regular” user.
Regular users rely on a trust system that they build themselves by interacting with Discourse.
Staff members can be an admin in which case they have access to every possible configuration. Or they can be a moderator to moderate discussions .
I am expecting very few admins like 3-5 and as much moderator as needed.
All that to be said, we won’t have “advanced” groups needed as most of the permission should be managed by people themselves.
Now let’s look at the different authentication options.
Delegate authentication to Linux Foundation
As a Linux Foundation project, we have access to their sso
The benefits are the number of authentication methods allowed.
LF account and Google/Facebook/Linkedin/Github
Keep authentication in discourse
No external dependencies
We can configure Google/Github/Linkedin/Twitter/Facebook
We use the default Discourse user registration process
Members are allowed to delete their account
We could reuse existing Jenkins accounts but honestly I am strongly opposed.
Keeping everything inside Discourse means no third-dependencies like having to open support on Linux foundation, and no extra work excepted the initial integration configuration. So my preference would be that one but I may miss something.
Which authentication method do we use?
Linux Foundation
Discourse
0voters
If we decide to go with the second approach and let Discourse handle authentication
then we must agree on which additional social network we want to use between Github/Linkedin/Google/Twitter/Facebook. In this case, which social network should we allow?
Google
Github
Facebook
Linkedin
Twitter
None
0voters
PS: Considering that we are currently working on invite-only to keep control on the number of registration until we decide on a method.
Feel free to provide feedback or request access here
After additional testing, it seems that additional authentication methods comes on top of the default one which is local entry. Important options are
invite only
All new users must be explicitly invited by trusted users or staff. Public registration is disabled.
enable local logins
Enable local username and password login based accounts. WARNING: if disabled, you may be unable to log in if you have not previously configured at least one alternate login method.
allow new registrations
Allow new user registrations. Uncheck this to prevent anyone from creating a new account.
enable github logins
Enable GitHub authentication, requires github_client_id and github_client_secret.
=> I enabled this one for testing purpose but it requires “allow new registrations” in order to work
Disabling local logins seems a bit risky to me as even for admin operation we would rely on a third identity service
I don’t have strong arguments that favor one over the other. I think that we want a larger community of people to be allowed to authenticate to the Discourse system without requiring that they register for a Jenkins LDAP account. I like that both proposals avoid using the Jenkins LDAP server because that shifts one system away from authenticating with the Jenkins LDAP server. Our other forum and chat systems (Google groups, Gitter, IRC) are not authenticated with the Jenkins LDAP server, so it seems quite reasonable to not authenticate this system with Jenkins LDAP.
The Discourse with GitHub proposal aligns well for contributors to the Jenkins GitHub repositories but may not align well for Jenkins users that are not directly contributing to Jenkins GitHub repositories.
The Discourse with LinkedIn proposal aligns with the Jenkins social network that has more subscribers to the Jenkins social media account on that platform than on Twitter or Facebook.
The Discourse with Twitter proposal aligns with a social network that I believe is even more widely used that LinkedIn, even though the number of followers of the Jenkins twitter account is less than the number of followers of the Jenkins LinkedIn account.
I’m a bit more indifferent because I already signed up for a linux foundation account for board reasons. My prefrence is firmly github, as its a requirement for any contributions to the project and easily map users on here with PR requests and stuff. Even down the line being able to give badges for certain type of contributions and stuff.
Using linux foundation sounds nice, but it’ll require the overwhelming majority to create a new account anyways, plus it doesn’t actually remove the need to manage accounts, just passwords. Passwords would be linux foundation, and we’d have to direct people there. The same would be true for github, but github at least is a very visible known entity.
I totally missed this, and was surprised it was enabled. @oleg-nenashev its enabled for testing, so don’t think we should make any announcements yet
I think its okay because its a hosted solution and we could reach out to their support incase of emergencies. Logins are only done when your logged out, so one of the “staff” members are probably still logged in.
I did notice because we have it manditory for staff to have 2fa enabled, that after logging in with github, I also had to login again then enter mfa, so I suspect there’s a way to disable local reg but still have it for existing accounts. I’ll do some googlin’
That’s not the best, normally when you use an external provider local 2fa is ignored =/
i.e. I have 2fa setup on my github to login, but I guess in most cases that orgs would have require 2fa so that’s ok whereas here we can’t require that =/
I’m in favor of as much auth. method as possible so that it would be a no-brainer for the users: whatever kind of external SSO ensures that the bar is lowered to participate on discussions.
Assuming that end-user is responsible for the choice around their data and usage pattern.
A few points:
Not sure about the state of “sending requests to external providers when opening the login windows”: we might want to double check exhaustively. For GitHub, everything is stored on Discourse servers, but what about Facebook, Linkedin, etc. (Thinking about the case where a request is made for the image of the log-in button to external server, allowing to trace user back even if no account or not logged-in). WDYT?
Might be obvious, but keeping access in read-only (e.g. without requiring authentication) to the forum is really important for me, as I don’t see why reading a subject should make mandatory auth. I understand that Discourse had this option enabled by default (“ala Medium: after 3-4 read topics, a popup asking for auth appears”) but it was disabled by one of you: that’s a great thing!
Of course, posting to a forum should require authentication though, to ensure some kind of moderation apply when expressing (Code of Conduct accepted, GDPR, etc.)
I wasn’t able to reproduce any error while using Github SSO (macOS Intel, Firefox latest, uBlock enabled with default configuration): it’s important that we identify the issue or it will be shadowe and could cause frustration to end users: can the ones of you affected by the mentionned issue describe the reproduction?
It seems like you identified that it’s when 2FA is enforced on Discourse’s side to a group (Staff) which forbids use of external authentication? If it is the case, I’m in favor of keeping SSOs, and switch the discussion to another dedicated topic around staff management (as it might induces moderators)
Btw, thanks y’all for discussing this topic, it’s really heart-warming to see such activity, keep the good work!
I don’t understand what this is referring to. The login is oauth, profile information is pre-populated to discourse, then people can update as they want. The same should be true for the others. I will say though if you enable anything facebook, facebook will track everything there is to know on the site. I already have firefox icon saying facebook is blocked, so they seem to be doing it already as is.
Yea, just like everything else, anonymous reads, authenticated writes
did you try enabling 2fa on your discourse account? I’m not sure you even can as an external auth’d user. I might get my friend to try.
I just signed up today and I was … surprised I need to authenticate with something other than https://accounts.jenkins.io, so I ended up creating a local account - are there any plans to give it up altogether?
Not sure what you mean by “it” in the phrase “give it up altogether”.
If you mean dropping support for the Jenkins LDAP server, then the answer is probably not. The Jenkins LDAP server has over 100k registered accounts and controls access to the Jenkins issue tracker (https://issues.jenkins.io). However, we’ve found that registering for a Jenkins LDAP account is sometimes a barrier for users, so the Discourse system intentionally allows GitHub based authentication instead of requiring a Jenkins LDAP account.
If “it” in the phrase “give it up altogether” means giving up local accounts in Discourse, then I don’t think there is any idea to prevent users from having a local Discourse account.
The idea was to reduce the barriers for users. A GitHub account is quite common, so that is currently allowed. I believe other account types are also open for consideration.
Just to share a bit more context with @saper et al, one year ago we had a massive infra issue caused by the Kubernetes cluster failure and multi-month LDAP database history loss (yes, broken backups…). It caused a lot of complications for users and major SDLC security concerns. Read more: https://groups.google.com/g/jenkinsci-dev/c/3UvrCTflXGk/m/_W1qzzklBgAJ
One of the retrospective outcomes was the agreement that we want to…
Stop managing user identities on our own, especially for Jira and other mass user services. We’d like to keep LDAP for cases when permissions are actually required (e.g. administrative access to Jenkins Infra services)
Move user identity management somewhere, preferably transfer user accounts to the Linux Foundation systems. Maintaining and securing user identities is a big overhead for the Infra team, and we want to avoid it for the vast majority of users
No that’s right, until we have a better view on the future of accounts.jenkins.io, we prefer to avoid it as much as possible.
Discourse already provide an easy way to create and delete your account, while accounts.jenkins.io doesn’t allow you to delete your account. This is a manual procedure that infrastructure staff needs to do.
We are still at learning how to manage this discourse service, so not everything is perfect but we hope that it will facilitate discussion within the Jenkins community.
.