The above commit was over-applied in #3168 to Generic Oauth in
addition to GitHub Oauth based on an assumption. It should only
have been applied to GitHub-specific OAuth. This over-application
introduced a bug where GitHub Enterprise did not work anymore.
If an account had multiple emails, the current implementation would
always select the first one regardless of any other settings. This fixes
it so it only chooses the primary email address that is verified.
This also fixes the generic oauth2 to require verified and primary to be
true if they are present. If they are not present, they are not
required.
This covers cases where users are or are not members of organizations as
well as whether or not they should have access to the application based
on their organization membership.
It's useful for operators to classify users into separate groups which
we have termed "organizations". For other OAuth providers, the notion of
an organization typically fell along company lines. For example,
MegaCorp might have a "MegaCorp" GitHub organiztion, and all email
addresses would have the domain "megacorp.com".
Auth0 is slightly different in that MegaCorp would likely run their own
Auth0 provider for their internal services, so "organizations" in Auth0
are no longer synonymous with "large organizations" (or companies).
Instead, Auth0 organizations could be used to restrict access to
Chronograf instances based on team membership within an organization.
To make use of Auth0 organizations, operators should modify users'
app_metadata to include the key "organization". Its value should be the
organization which that user belongs to. This can be done automatically
through arbitrary rules using Auth0 Rules.
Auth0 is an OpenID Connect compliant OAuth2 provider, so we're able to
re-use the generic OAuth2 provider to implement it. The routes required
by Auth0 have been hardcoded for user convenience.
Also, Auth0 requires users to register a subdomain of auth0.com when
signing up. This must be provided to chronograf through the
`--auth0-domain` parameter (or `AUTH0_DOMAIN` ENV). This is **distinct**
from the `PUBLIC_URL`. For example, for a Chronograf hosted at
`http://www.example.com`, and an Auth0 domain of
`http://oceanic-airlines.auth0.com`, a client-id of `notpennysboat` and a
client-secret of `4-8-15-16-23-42`, the command line options would look
like:
```
chronograf \
--auth0-domain=http://oceanic-airlines.auth0.com \
--auth0-client-id=notpennysboat \
--auth0-secret=4-8-15-16-23-24
--public-url=http://www.example.com
-t `uuidgen`
```
Updated the logout link in the UI to use a link provided by the
/chronograf/v1/ endpoint. We also replaced many instances of string
concatenation of URL paths with path.Join, which better handles cases
where prefixed and suffixed "/" characters may be present in provided
basepaths. We also refactored how Basepath was being prefixed when using
Auth. Documentation was also updated to warn users that basepaths should
be applied to the OAuth callback link when configuring OAuth with their
provider.
* WIP
* Fix JWTs for auth-durations less than 5 mins
For auth-duration = 0 the JWT now understands that there does not
need to be duration checks.
For auth-duration < 5 minutes > 0 the JWT lifespan will be 1/2
of auth-duration to allow one extension
There is likely a range of very short auth-duration times like, say,
less than 5 seconds that would never allow a person to login simply
because the time of issue and request is longer.
* Update changelog
JWTs will only life five minutes into the future. Any time
the server receives an authenicated request, the JWT's expire at
will be extended into the future.
Jared Scheib
Jonathan A. Sternberg
Benjamin Schweizer
Brandon Farmer
Michael Desa
Benjamin Schweizer
Benjamin Schweizer
Chris Goller
Tim Raymond
Jade McGough
Kent Wang