No description
Find a file
Eric Chiang 221a1ad7a0 user: fix password info JSON encoding to survive round trips
PasswordInfos are marshaled when storing them in the database as
part of the local connector. However, the custom unmarsheler
defined could not unmarshal the standard marshling of this struct.

Add a struct tag to the Password field to correct this.

Closes #332
2016-02-23 16:25:56 -08:00
admin *: remove in memory connector config repo 2016-02-12 13:19:05 -08:00
client *: remove in memory client repo 2016-02-12 13:19:05 -08:00
cmd *: don't allow sqlite3 if --no-db flag not specified 2016-02-12 13:19:05 -08:00
connector user: fix password info JSON encoding to survive round trips 2016-02-23 16:25:56 -08:00
contrib worker start command missing registration and emailer config. exported as env variables like other properties. 2016-01-26 20:40:50 -08:00
db db: clean up quote and executor function calls, improve translate docs 2016-02-16 18:19:23 -08:00
Documentation Documentation: update roadmap with issue and PR numbers 2016-02-18 11:08:03 -08:00
email email: templatizer takes global context. 2015-10-30 14:53:52 -07:00
examples Merge pull request #204 from coreos/update-dev-documentation 2015-12-07 15:43:41 -08:00
functional functional: remove in memory connector configs from ldap tests 2016-02-16 15:21:38 -08:00
Godeps Godeps: add sqlite3 2016-02-12 13:19:05 -08:00
integration *: remove in memory connector config repo 2016-02-12 13:19:05 -08:00
pkg pkg,cmd: add document generator tool 2016-02-01 16:09:23 -08:00
refresh *: remove in memory refresh repo 2016-02-12 13:19:05 -08:00
repo *: remove in memory user repo 2016-02-12 13:19:05 -08:00
schema Merge pull request #285 from ericchiang/api_docs 2016-02-01 16:26:05 -08:00
server *: don't allow sqlite3 if --no-db flag not specified 2016-02-12 13:19:05 -08:00
session session: remove unused function argument 2016-02-16 18:20:48 -08:00
static *: fix --no-db client decoding 2016-02-12 13:19:05 -08:00
user user: fix password info JSON encoding to survive round trips 2016-02-23 16:25:56 -08:00
.gitignore *: move original project to dex 2015-08-18 11:26:57 -07:00
.travis.yml Merge pull request #304 from ericchiang/sqlite3 2016-02-19 16:03:15 -08:00
build *: use go install instead of go build in build script 2016-02-12 13:19:05 -08:00
build-docker-push git-version: script detection of git tag/commit 2015-12-16 14:28:20 -08:00
build-units *: move original project to dex 2015-08-18 11:26:57 -07:00
CONTRIBUTING.md *: move original project to dex 2015-08-18 11:26:57 -07:00
cover *: move original project to dex 2015-08-18 11:26:57 -07:00
DCO *: move original project to dex 2015-08-18 11:26:57 -07:00
Dockerfile Dockerfile: use right env var for email templates 2015-10-22 12:07:07 -07:00
Dockerfile-builder Dockerfile: use go 1.4 to build 2015-10-22 14:02:51 -07:00
env *: use go install instead of go build in build script 2016-02-12 13:19:05 -08:00
git-version git-version: script detection of git tag/commit 2015-12-16 14:28:20 -08:00
go-docker Dockerfile: use go 1.4 to build 2015-10-22 14:02:51 -07:00
LICENSE *: move original project to dex 2015-08-18 11:26:57 -07:00
MAINTAINERS *: update MAINTAINERS 2016-01-08 14:54:39 -08:00
NOTICE *: move original project to dex 2015-08-18 11:26:57 -07:00
README.md README: add note about roadmap and google group 2016-02-10 09:52:05 -08:00
release release: script the building of release artifacts 2015-12-16 14:28:34 -08:00
test *: use go install instead of go build in build script 2016-02-12 13:19:05 -08:00
test-functional *: use go install instead of go build in build script 2016-02-12 13:19:05 -08:00

dex

Build Status Docker Repository on Quay.io GoDoc

dex is a federated identity management service. It provides OpenID Connect (OIDC) and OAuth 2.0 to users, and can proxy to multiple remote identity providers (IdP) to drive actual authentication, as well as managing local username/password credentials.

We named the project 'dex' because it is a central index of users that other pieces of software can authenticate against.

Architecture

dex consists of multiple components:

  • dex-worker is the primary server component of dex
    • host a user-facing API that drives the OIDC protocol
    • proxy to remote identity providers via "connectors"
    • provides an API for administrators to manage users.
  • dex-overlord is an auxiliary process responsible for various administrative tasks:
    • rotation of keys used by the workers to sign identity tokens
    • garbage collection of stale data in the database
    • provides an API for bootstrapping the system.
  • dexctl is a CLI tool used to manage a dex deployment
    • configure identity provider connectors
    • administer OIDC client identities
  • database; a database is used to for persistent storage for keys, users, OAuth sessions and other data. Currently Postgres (9.4+) is the only supported database.

A typical dex deployment consists of N dex-workers behind a load balanacer, and one dex-overlord. The dex-workers directly handle user requests, so the loss of all workers can result in service downtime. The single dex-overlord runs its tasks periodically, so it does not need to maintain 100% uptime.

Who Should Use Dex?

A non-exhaustive list of those who would benefit from using dex:

  • Those who want a language/framework-agnostic way to manage authentication.
  • Those who want to federate authentication from mutiple providers of differing types.
  • Those who want to manage user credentials (eg. username and password) and perform authentication locally
  • Those who want to create an OIDC Identity Provider for multiple clients to authenticate against.
  • Those who want any or all of the above in a Free and Open Source project.

Getting help with dex

  • For bugs and feature requests (including documentation!), file an issue.
  • For general discussion about both using and developing dex, join the dex-dev mailing list.
  • For more details on dex development plans, check out the roadmap.

Connectors

Remote IdPs could implement any auth-N protocol. Connectors contain protocol-specific logic and are used to communicate with remote IdPs. Possible examples of connectors could be: OIDC, LDAP, Local credentials, Basic Auth, etc.

dex ships with an OIDC connector, useful for authenticating with services like Google and Salesforce (or even other dex instances!) and a "local" connector, in which dex itself presents a UI for users to authenticate via dex-stored credentials.

Future connectors can be developed and added as future interoperability requirements emerge.

Relevant Specifications

These specs are referenced and implemented to some degree in the jose package of this project.

OpenID Connect (OIDC) is broken up into several specifications. The following (amongst others) are relevant:

Example OIDC Discovery Endpoints

Next steps:

If you want to try out dex quickly with a single process and no database (do not run this way in production!) take a look at the dev guide.

For running the full stack check out the getting started guide.

Coming Soon

  • Multiple backing Identity Providers
  • Identity Management
  • Authorization

Similar Software

Auth0

Auth0 is a commercial product which implements the OpenID Connect protocol and JWT. It comes with built-in support for 30+ social providers (and provide extenibility points to add customs); enterprise providers like ADFS, SiteMinder, Ping, Tivoli, or any SAML provider; LDAP/AD connectors that can be run behind firewalls via an open source agent/connector; built-in user/password stores with email and phone verification; legacy user/password stores running Mongo, PG, MySQL, SQL Server among others; multi-factor auth; passwordless support; custom extensibility of the auth pipeline through node.js and many other things.

You could chain dex with Auth0, dex as RP and Auth0 as OpenId Connect Provider, and bring to dex all the providers that comes in Auth0 plus the user management capabilities.

CloudFoundry UAA

The UAA is a multi tenant identity management service, used in Cloud Foundry, but also available as a stand alone OAuth2 server.

OmniAuth

OmniAuth provides authentication federation at the language (Ruby) level, with a wide range of integrations available.

Okta

Okta is a commercial product which is similar to dex in that for it too, identity federation is a key feature. It connects to many more authentication providers than dex, and also does the federation in the oppposite direction - it can be used as a SSO to other identity providers.

Shibboleth

Shibboleth is an open source system implementing the SAML standard, and can federate from a variety of backends, most notably LDAP.