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.
* User can now set oauth cookie session duration via the CLI to any duration or to expire on browser close
* Refactor GET 'me' into heartbeat at constant interval
* Add ping route to all routes
* Add /chronograf/v1/ping endpoint for server status
* Refactor cookie generation to use an interface
* WIP adding refreshable tokens
* Add reminder to review index.js Login error handling
* Refactor Authenticator interface to accommodate cookie duration and logout delay
* Update make run-dev to be more TICKStack compliant
* Remove heartbeat/logout duration from authentication
* WIP Refactor tests to accommodate cookie and auth refactor
* Update oauth2 tests to newly refactored design
* Update oauth provider tests
* Remove unused oauth2/consts.go
* Move authentication middleware to server package
* Fix authentication comment
* Update authenication documentation to mention AUTH_DURATION
* Update /chronograf/v1/ping to simply return 204
* Fix Makefile run-dev target
* Remove spurious ping route
* Update auth docs to clarify authentication duration
* Revert "Refactor GET 'me' into heartbeat at constant interval"
This reverts commit 298a8c47e1431720d9bd97a9cb853744f04501a3.
Conflicts:
ui/src/index.js
* Add auth test for JWT signing method
* Add comments for why coverage isn't written for some areas of jwt code
* Update auth docs to explicitly mention how to require re-auth for all users on server restart
* Add Duration to Validation interface for Tokens
* Make auth duration of zero yield a everlasting token
* Revert "Revert "Refactor GET 'me' into heartbeat at constant interval""
This reverts commit b4773c15afe4fcd227ad88aa9d5686beb6b0a6cd.
* Rename http status constants and add FORBIDDEN
* Heartbeat only when logged in, notify user if heartbeat fails
* Update changelog
* Fix minor word semantics
* Update oauth2 tests to be in the oauth2_test package
* Add check at compile time that JWT implements Tokenizer
* Rename CookieMux to AuthMux for consistency with earlier refactor
* Fix logout middleware
* Fix logout button not showing due to obsolete data shape expectations
* Update changelog
* Fix proptypes for logout button data shape in SideNav
This allows operators to permit access to Chronograf only to users belonging
to a set of specific Heroku organizations. This is controlled using the
HEROKU_ORGS env or the --heroku-organizations switch.
Information on setting up Heroku and Google authentication has been
added. Also, the information about the design has been updated and moved
to the oauth2 package docs along with updated diagrams to match with
developer expectations about where design-related documentation should
be found.
JWTMux was a disingenuous name because while JWTs are a very good choice
for a cookie encoding, they were not strictly required for use with this
mux. To better indicate the responsibilities of this mux, it's been
renamed "CookieMux," since its responsibilities end with persisting the
oauth2.Authenticator's encoded state in the browser. It is up to the
oauth2.Authenticator to choose the encoding.
This adds an Oauth2 Provider for authenticating users against Heroku's
API. In contrast to other Providers, a maintained client library for
interacting with the Heroku API was not available, so direct HTTP calls
are made instead. This follows with their documentation posted here:
https://devcenter.heroku.com/articles/oauth2-heroku-go
Jared Scheib
Chris Goller
Michael Desa
Tim Raymond
Jade McGough
Kent Wang
Jared Scheib