sso_*: allow simultaneous use of Validators

[Jusshersmith]

Problem

The connection between AllowedEmailDomains, AllowedEmailAddresses, and AllowedGroups is unclear. If all specified, they don't work together well which causes awkward workarounds to be put into place.

Solution

Introduce a more structured 'Validator' type within SSO, allowing us to create better and clearer dynamics between these settings (and any other validators that may be added in the future).

There are currently three separate validators:

• Email Domain
• Email Address
• Email Group

SSO will now allow the request through providing at least one of these validators pass.

Notes

• I would suggest looking at the following files together:

- internal/pkg/options/validators.go
- internal/pkg/options/email_address_validator.go
- internal/pkg/options/email_domain_validator.go
- internal/pkg/options/email_group_validator.go

- internal/proxy/proxy.go
- internal/proxy/oauthproxy.go

- internal/auth/authenticator.go
- internal/auth/mux.go
- internal/auth/options.go

- internal/pkg/options/mock_validator.go
- internal/auth/authenticator_test.go
- internal/proxy/oauthproxy_test.go

- internal/pkg/options/email_address_validator_test.go
- internal/pkg/options/email_domain_validator_test.go

• This also changes the use of the * wildcard within AllowedEmailDomains and AllowedEmailAddresses. The wildcard will be ignored if other domains/email addresses are also passed with it, choosing to follow the most restrictive path.

• On second thoughts..I think it may have been clearer to recreate the validator files from scratch!

[codecov]

Codecov Report

Merging #253 into master will increase coverage by 0.1%.
The diff coverage is 62.04%.

@@            Coverage Diff            @@
##           master     #253     +/-   ##
=========================================
+ Coverage   62.04%   62.14%   +0.1%     
=========================================
  Files          50       53      +3     
  Lines        4105     4169     +64     
=========================================
+ Hits         2547     2591     +44     
- Misses       1370     1391     +21     
+ Partials      188      187      -1

Impacted Files	Coverage Δ
internal/pkg/options/email_group_validator.go	0% <0%> (ø)
internal/pkg/options/mock_validator.go	0% <0%> (ø)
internal/proxy/proxy.go	20.45% <0%> (-1.5%)	⬇️
internal/pkg/options/validators.go	0% <0%> (ø)
internal/pkg/options/email_address_validator.go	100% <100%> (ø)	⬆️
internal/auth/options.go	78.57% <100%> (ø)	⬆️
internal/auth/authenticator.go	86.18% <100%> (+0.37%)	⬆️
internal/pkg/options/email_domain_validator.go	100% <100%> (ø)	⬆️
internal/proxy/oauthproxy.go	54.1% <55.55%> (+3.98%)	⬆️
internal/auth/mux.go	75% <75%> (ø)	⬆️
... and 4 more

[Jusshersmith]

Some additional test files are also needed, i.e: internal/pkg/options/email_group_validator_test.go

[Jusshersmith]

TODO: Not a huge issue, but if any of the errors are duplicated (which is currently possible) then they'll also be duplicated on the error page -- which we could easily avoid if we wanted to.

[Jusshersmith]

Example error page with all three current validators failing due to invalid email/group membership:

There are four situations in which these validators are ran (two in Proxy, two in Authenticator). This is currently applied to the two situations (one in each component) where an error page is explicitly created rather than a predefined error (ErrUserNotAuthorized for example) is returned and created into an error page up the call chain.

The expectation is for the errors returned by the validators to be appropriate for display to end users: https://github.com/buzzfeed/sso/pull/253/files#diff-dca459fc7951884cb7d06d6213cd5710R14-R16

cc @jphines

[jphines]

SGTM. We could clean up the visual a little bit but let's do that in a follow up.