f18d7afc6f
Before, you could not POST your credentials to a password-connector's
endpoint without GETing that endpoint first. While this makes sense for
browser clients; automated interactions with Dex don't need to look at
the password form to fill it in.
A symptom of that missing GET was that the POST succeeded (!) with
login successful: connector "", username="admin", email="admin@example.com", groups=[]
Note the connector "". A subsequent call to finalizeLogin would then
fail with
connector with ID "" not found: failed to get connector object from storage: not found
Now, the connector ID of an auth request will be updated for both GETs
and POSTs.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
|
||
|---|---|---|
| Documentation | ||
| api | ||
| cmd | ||
| connector | ||
| examples | ||
| scripts | ||
| server | ||
| storage | ||
| vendor | ||
| version | ||
| web | ||
| .dockerignore | ||
| .gitignore | ||
| .travis.yml | ||
| DCO | ||
| Dockerfile | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| README.md | ||
| glide.lock | ||
| glide.yaml | ||
| glide_test.go | ||
README.md
dex - A federated OpenID Connect provider
Dex is an identity service that uses OpenID Connect to drive authentication for other apps.
Dex is NOT a user-management system, but acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.
ID Tokens
ID Tokens are an OAuth2 extension introduced by OpenID Connect and dex's primary feature. ID Tokens are JSON Web Tokens (JWTs) signed by dex and returned as part of the OAuth2 response that attest to the end user's identity. An example JWT might look like:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg
ID Tokens contains standard claims assert which client app logged the user in, when the token expires, and the identity of the user.
{
"iss": "http://127.0.0.1:5556/dex",
"sub": "CgcyMzQyNzQ5EgZnaXRodWI",
"aud": "example-app",
"exp": 1492882042,
"iat": 1492795642,
"at_hash": "bi96gOXZShvlWYtal9Eqiw",
"email": "jane.doe@coreos.com",
"email_verified": true,
"groups": [
"admins",
"developers"
],
"name": "Jane Doe"
}
Because these tokens are signed by dex and contain standard-based claims other services can consume them as service-to-service credentials. Systems that can already consume OpenID Connect ID Tokens issued by dex include:
For details on how to request or validate an ID Token, see "Writing apps that use dex".
Kubernetes + dex
Dex's main production use is as an auth-N addon in CoreOS's enterprise Kubernetes solution, Tectonic. Dex runs natively on top of any Kubernetes cluster using Third Party Resources and can drive API server authentication through the OpenID Connect plugin. Clients, such as the Tectonic Console and kubectl, can act on behalf users who can login to the cluster through any identity provider dex supports.
More docs for running dex as a Kubernetes authenticator can be found here.
Documentation
- Getting started
- Intro to OpenID Connect
- Writing apps that use dex
- What's new in v2
- Custom scopes, claims, and client features
- Storage options
- gRPC API
- Using Kubernetes with dex
- Identity provider logins
- Client libraries
Reporting a security vulnerability
Due to their public nature, GitHub and mailing lists are NOT appropriate places for reporting vulnerabilities. Please refer to CoreOS's security disclosure process when reporting issues that may be security related.