Unify the interface for reading web statics. Now it could read an
OS directory or get the content on live
One could use
//go:embed static
var webFiles embed.FS
anywhere and config dex server to take the file system by setting
WebConfig{WebFS: webFiles}
Signed-off-by: Rui Yang <ruiya@vmware.com>
Co-authored-by: Aidan Oldershaw <aoldershaw@pivotal.io>
* Added /device/token handler with associated business logic and storage tests.
Perform user code exchange, flag the device code as complete.
Moved device handler code into its own file for cleanliness. Cleanup
* Removed PKCE code
* Rate limiting for /device/token endpoint based on ietf standards
* Configurable Device expiry
Signed-off-by: justin-slowik <justin.slowik@thermofisher.com>
connector/microsoft implements authorization strategy via Microsoft's
OAuth2 endpoint + Graph API. It allows to choose what kind of tenants
are allowed to authenticate in Dex via Microsoft:
* common - both personal and business/school accounts
* organizations - only business/school accounts
* consumers - only personal accounts
* <tenant uuid> - only account of specific tenant
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
This way, the user who has selected, say, "Log in with Email" can make up
their mind, and select a different connector instead.
However, if there's only one connector set up, none of this makes sense -- and
the link will thus not be displayed.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
This allows users of the LDAP connector to give users of Dex' login
prompt an idea of what they should enter for a username.
Before, irregardless of how the LDAP connector was set up, the prompt
was
Username
[_________________]
Password
[_________________]
Now, this is configurable, and can be used to say "MyCorp SSO Login" if
that's what it is.
If it's not configured, it will default to "Username".
For the passwordDB connector (local users), it is set to "Email
Address", since this is what it uses.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
connector/linkedin implements authorization strategy via LinkedIn's
OAuth2 endpoint + profile API.
It doesn't implement RefreshConnector as LinkedIn doesn't provide any
refresh token at all (https://developer.linkedin.com/docs/oauth2, Step 5
— Refresh your Access Tokens) and recommends ordinary AuthCode exchange
flow when token refresh is required.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
Switch from using "text/template" to "html/template", which provides
basic XSS preventions. We haven't identified any particular place
where unsanitized user data is rendered to the frontend. This is
just a preventative step.
At the same time, make more templates take pure URL instead of
forming an URL themselves using an "authReqID" argument. This will
help us stop using the auth req ID in certain places, preventing
garbage collection from killing login flows that wait too long at
the login screen.
Also increase the login session window (time between initial
redirect and the user logging in) from 30 minutes to 24 hours,
and display a more helpful error message when the session expires.
How to test:
1. Spin up dex and example with examples/config-dev.yaml.
2. Login through both the password prompt and the direct redirect.
3. Edit examples/config-dev.yaml removing the "connectors" section.
4. Ensure you can still login with a password.
(email/password is "admin@example.com" and "password")
This PR reworks the web layout so static files can be provided and
a "themes" directory to allow a certain degree of control over logos,
styles, etc.
This PR does NOT add general support for frontend customization,
only enough to allow us to start exploring theming internally.
The dex binary also must now be run from the root directory since
templates are no longer "compiled into" the binary.
The docker image has been updated with frontend assets.
"state" means something specific to OAuth2 and SAML so we don't
want to confuse developers who are working on this.
Also don't use "session" which could easily be confused with HTTP
cookies.
