Add single sign-on support via SSPI on Windows

[quasoft]

This pull request adds support for Single single-on authentication with Kerberos/NTLM by implementing the protocol defined by RFC4559 (SPNEGO-based HTTP Authentication in Microsoft Windows) to exchange authentication data between the web browser and the HTTP server, and using the Security Support Provider Interface (SSPI) to perform the authentication.

This is a sample implementation of the design proposed with #8462. The referenced proposal contains more details on the design choices.

[guillep2k]

I'm currently using Gitea in a Linux system with PAM authentication for validating the user accounts from our AD. That's because my (CentOS 7) has sssd integration with our AD. I wonder if your solution could be integrated with that (I don't even know if pam can be compiled on Windows).

Regarding the "Disable Sign On" button, I find it adds too much clutter to the login page. I'd rather make "Sign in" a drop-down menu:

I don't mean to use ticks for the drop-down, the user just clicks the option they want; no cookies, no preferences.

When clicking to "Sign In" (the header of the menu), it uses a default log in mode, which the admin can select in app.ini

[zeripath]

The continuous integration is failing because you need to:

Please run 'make vendor' and commit the result:

[quasoft]

@guillep2k Thank you for the feedback.

You are actually right that an additional button in the navbar adds too much clutter and a dropdown will look better. Will definitely change it to a dropdown.

Initially, I added a similar Login with a local account button that opens the user/login page with a suppress_sso=1 (user/login?suppress_sso=1) query parameter. Then I figured out that I have to persist this value as a hidden input in the login form (in case the user types a wrong password - writing a wrong local username or password reloads user/login, but without the query parameter). It turned out the same has to be done on the user registration page, the forgot password page and probably a few more.

That's why I decided to use a cookie. It allows the user to toggle between Single Sign-On and the default login behavior on the go, with a single click. And it does not require modification of existing handlers or templates related to the login process.

But if anyone can give an idea, how to check (at the middleware level, inside Contexter) if current page requires the user to be signed in, SSO could be automatically disabled on all pages that do not require authentication, which would make the use of the cookie unnecessary.
If I understand it correctly this decision is made when routes are created. For example in:

gitea/routers/routes/routes.go

Lines 609 to 618 in f2a3abc

	m.Group("/repo", func() {
	m.Get("/create", repo.Create)
	m.Post("/create", bindIgnErr(auth.CreateRepoForm{}), repo.CreatePost)
	m.Get("/migrate", repo.Migrate)
	m.Post("/migrate", bindIgnErr(auth.MigrateRepoForm{}), repo.MigratePost)
	m.Group("/fork", func() {
	m.Combo("/:repoid").Get(repo.Fork).
	Post(bindIgnErr(auth.CreateRepoForm{}), repo.ForkPost)
	}, context.RepoIDAssignment(), context.UnitTypes(), reqRepoCodeReader)
	}, reqSignIn)

repo routes have a group handler reqSignIn, which enforces the user to be signed in, but that is executed after all middlewares.
Would it somehow be possible to check inside a middleware if the reqSignIn or ignSignIn handlers have been assigned to the current page?

As for sssd I haven't used it with active directory, but I believe that plugin authentication modules are a Linux thing. A Gitea web server running on Linux could authenticate to AD with GSSAPI (eg, I believe that is what PostgreSQL uses on Linux). And there seems to exist Golang packages that implement Kerberos with GSSAPI, so at a later stage that would also be possible by writing a gssapi_linux.go plugin inside modules/auth/sso/.

[quasoft]

@zeripath Thanks, I will run make vendor together with my next commit.

[quasoft]

Updated vendor directory and made two other changes:

1. Replaced buttons Enable Single Sign-On and Disable Single Sign-On on the anonymous dashboard with a dropdown menu with hover text "Single Sign-On":
   

2. handleSignIn function is not called when accessing API paths, /manifest.json and /serviceworker.js.
   It should not be called on API paths because that would change existing behaviour for Basic authentication, OAuth or Reverse proxy authentication.

        // Try to sign in with each of the enabled plugins
	for _, ssoMethod := range sso.Methods() {
		if !ssoMethod.IsEnabled() {
			continue
		}
		user = ssoMethod.VerifyAuthData(ctx)
		if user != nil {
			// Make sure requests to API paths and PWA resources do not create a new session
			if !IsAPIPath(ctx.Req.URL.Path) && !IsPWAResource(ctx.Req.URL.Path) {
				handleSignIn(ctx, sess, user)
			}
			_, isBasic := ssoMethod.(*sso.Basic)
			return user, isBasic
		}
	}

[quasoft]

Made a few more changes:

1. First, Introduced a Priority() method to the SingleSignOn interface. This method should return an integer, that determines the order in which authentication plugins are executed.

// SingleSignOn represents a SSO authentication method (plugin) for HTTP requests.
type SingleSignOn interface {
	...
	// Priority determines the order in which authentication methods are executed.
	// The lower the priority, the sooner the plugin is executed.
	Priority() int
	...
}

2. Added a second parameter to the VerifyAuthData() of the SingleSignOn interface that accepts arguments of type session.Store. The purpose is to allow authentication plugins to use the data of the session object when making the decision to authenticate the request:

// SingleSignOn represents a SSO authentication method (plugin) for HTTP requests.
type SingleSignOn interface {
	...
	VerifyAuthData(ctx *macaron.Context, sess session.Store) *models.User
}

3. Introduced a new SSO plugin session.go, which checks if there is a user uid stored in the session and returns the corresponding user object for that uid (that behaviour was extracted from modules/auth/auth.go).

4. Order of execution of plugins set to (in order to keep existing behaviour before the pull request; random order was breaking integration tests for the /api/v1/admin/ path):

   • oauth2
   • session
   • reverseproxy
   • basic
   • sspi

   The SSPI plugin executes last, as it returns 401 if negotiation fails or should continue, which would prevent other authentication methods to execute at all.

[lafriks]

I was looking at the code and imho it would be way better if sspi would have been added as authorization source just like others currently are instead of app.ini settings

[quasoft]

@lafriks
To be honest I had only a very quick look at login sources and left with the impression that they (LDAP, SMTP, PAM, OAuth2) are only used for interactive login with username and password.

SPNEGO with SSPI does not require the user to enter any credentials, and uses only authentication data automatically populated by the browser to the Authroization header, so I felt single sign-on authentication would fit better at the middleware level. That's why I made it similar to reverse proxy authentication and basic authorization, which too rely only on headers present in the request to authenticate the user.

But I will definitely take a more detailed look at how login sources work. If I manage to integrate SSPI/SPNEGO as part of those sources, I will make a second pull request for this variant too.

[quasoft]

@lafriks As for settings only, those probably can be stored in the authentication sources DB table instead of in the app.ini file.

[lafriks]

My primary idea was that it could be enabled in auth sources, functionality can still happen in middleware

[quasoft]

Made a few more changes:

1. Moved SSPI activation and configuration from ini file to "Site Administration -> Authentication Sources" (as suggested by @lafriks):
   
2. Removed option for enabling SSPI from installer page.
3. Removed the Dropdown menu for temporary disabling of single sign-on and the cookie that stored the setting (suggested to remove cookie by @guillep2k ).
4. Added an "SSPI" button (tab) to the standard login page:
   
5. Changed the SSPI auth method to not try to perform authentication on public pages (eg. /user/login) or public resources (eg. /favicon.png)
6. Changed the SSPI auth method to include the template for the /user/login page when returning 401 status code. Thus the browser can display the standard login page of Gitea if negotiation by SPNEGO fails.

[quasoft]

Can anyone advise on the golangci-lint error?

[guillep2k]

@quasoft It looks like a bogus CI error. Try updating the branch to trigger the CI check again.

[guillep2k]

I' ve updated the branch for you (you'll have to git pull before pushing again), but the problem is still there. Two things come to my mind:

• Gitea currently needs go version 1.13; make sure you've used that on your copy.
• Gitea's CI runs under Linux. If you have any components that are Windows-only, you need to use build tags to leave them out of the build on other platforms. See auth/pam module for an example.

[quasoft]

Thanks, will check again for Windows-only components.

[codecov-io]

Codecov Report

Merging #8463 into master will decrease coverage by <.01%.
The diff coverage is 38.4%.

@@            Coverage Diff             @@
##           master    #8463      +/-   ##
==========================================
- Coverage   41.12%   41.11%   -0.01%     
==========================================
  Files         547      552       +5     
  Lines       71622    71829     +207     
==========================================
+ Hits        29454    29532      +78     
- Misses      38442    38569     +127     
- Partials     3726     3728       +2

Impacted Files	Coverage Δ
modules/auth/auth_form.go	100% <ø> (ø)	⬆️
routers/repo/http.go	35.38% <100%> (ø)	⬆️
routers/init.go	68.67% <100%> (+1.17%)	⬆️
modules/auth/auth.go	67.92% <100%> (+18.3%)	⬆️
routers/user/auth.go	12.03% <100%> (+0.15%)	⬆️
routers/admin/auths.go	30.71% <23.52%> (-1.52%)	⬇️
models/login_source.go	25.76% <23.52%> (-0.07%)	⬇️
modules/auth/sso/sso.go	28.12% <28.12%> (ø)
modules/auth/sso/basic.go	43.66% <43.66%> (ø)
modules/auth/sso/oauth2.go	60% <60%> (ø)
... and 11 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eb1b225...359cd8e. Read the comment docs.

[lafriks]

Looks very nice, thanks. Will review it next week, quite a big pr to review :)

[lafriks]

Small nit changes needed but otherwise LG-TM. Great work! Some parts was a bit hard to review because of lot of refactoring but I look how code is now structured. Thanks!

[quasoft]

Rebased and rebuilt public/js files.

[guillep2k]

Great work!! 🎉

[quasoft]

Thank you too for the time spend on this feature!

Working on this PR was very motivating and a great experience. Thanks!

[lafriks]

Thanks for your PR! ;)