Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sso_proxy: fix session revalidation/refresh when group validation isn't being used #286

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Jusshersmith
Copy link
Contributor

@Jusshersmith Jusshersmith commented Mar 11, 2020

Problem

When certain TTL's expire we revalidate or refresh the session (e.g. https://github.com/buzzfeed/sso/blob/master/internal/proxy/oauthproxy.go#L759-L764), which then ends up directly calling the ValidateGroup provider method (https://github.com/buzzfeed/sso/blob/master/internal/proxy/providers/sso.go#L381).

Because here we're not using the validator abstractions, if group validation isn't being utilised, then this causes a 403 with user is no longer in valid groups to be returned, requiring the user to refresh the page to progress further.

Solution

The logic within ValidateGroup to return a success when an empty slice of groups is passed in was removed during some refactoring as, when using 'validator' abstractions this was deemed bad behaviour**, but until we stop calling ValidateGroup directly and use those abstractions everywhere we need to maintain this behaviour.

#275 fixes this in a more permanent, stable fashion by replacing any remaining direct calls to ValidateGroup with calls to the validator abstractions, however until that is merged this is one possible temporary fix.

Notes

**This was deemed bad behaviour because if the group validator is the only validator in use (and not email domains or addresses), then allowing ValidateGroup to return successful if an empty list of groups is passed becomes a loophole to allow the defining of no validators, something which we explicitly prevent (https://github.com/buzzfeed/sso/blob/master/internal/proxy/options.go#L205-L213)

@Jusshersmith
Copy link
Contributor Author

Jusshersmith commented Mar 11, 2020

Looking back through this, I have some new thoughts:

Allowing the only defined validator to be used with a wildcard isn't new to SSO, and also actually remains possible using the other email domain/address validators. Historically, this has probably been classed as less of a 'loophole' and more of a 'workaround'.

It probably makes sense to offer the functionality to say "as long as the request comes from a valid user in my {insert provider} domain, then allow them". But seeing as this does reduce the security footprint somewhat, we should offer this as an explicit configuration option that can be set, rather than allowing a workaround by defining a validator with a wildcard.

My proposal then becomes:

Maybe we can combine the first and last point together.

@codecov
Copy link

codecov bot commented Mar 11, 2020

Codecov Report

Merging #286 into master will increase coverage by 0.09%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #286      +/-   ##
==========================================
+ Coverage   61.85%   61.94%   +0.09%     
==========================================
  Files          57       57              
  Lines        4638     4649      +11     
==========================================
+ Hits         2869     2880      +11     
  Misses       1556     1556              
  Partials      213      213
Impacted Files Coverage Δ
internal/pkg/options/email_address_validator.go 100% <ø> (ø) ⬆️
internal/pkg/options/email_domain_validator.go 100% <100%> (ø) ⬆️
internal/proxy/providers/sso.go 68.84% <100%> (+0.24%) ⬆️
internal/proxy/options.go 86.27% <100%> (+1.6%) ⬆️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant