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 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>
Do Refresh() by querying user's profile data.
Since LinkedIn doesn't provide refresh tokens at all, and the access
tokens have 60 days expiration, refresh tokens issued by Dex will fail
to update after 60 days.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
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>
We should always check if a user is in any orgs or teams specified
in config, and whether the groups scope is also included in client
requests. If not, return an error, because dex wouldn't have required
permissions to do the request anyway (need read:org).
Signed-off-by: zhuguihua <zhuguihua@cmss.chinamobile.com>
Change storace to storage in cmd/dex/config.go,
change userSearch to groupSearch in connector/ldap/ldap.go
When connecting to an LDAP server, there are three ways to connect:
1. Insecurely through port 389 (LDAP).
2. Securely through port 696 (LDAPS).
3. Insecurely through port 389 then negotiate TLS (StartTLS).
This PR adds support for the 3rd flow, letting dex connect to the
standard LDAP port then negotiating TLS through the LDAP protocol
itself.
See a writeup here:
http://www.openldap.org/faq/data/cache/185.html
Notice this when inspecting the code coverage results. For some
reason this test wasn't triggering the bad status code path, maybe
due to signature validation. Removing the comment fixed the code
coverage.
Support schemas that determine membership by having fields on the
user entity, instead of listing users on a groups entity. E.g. the
following schema is now supported when it wasn't previously:
cn=eric,cn=user,dn=exapmle,dn=com
objectClass=myPerson
cn: eric
uid: eric
email: eric@example.com
memberOf: foo
memberOf: bar
cn=foo,cn=group,dn=exapmle,dn=com
objectClass=myGroup
cn: foo
cn=bar,cn=group,dn=exapmle,dn=com
objectClass=myGroup
cn: bar
Introduces SAML tests which execute full response processing and
compare user attributes. tesdata now includes a full, self-signed
CA and documents signed using xmlsec1.
Adds deprication notices to existing tests, but don't remove them
since they still provide coverage.
When a SAML response provided multiple Assertion elements, only the
first one is checked for a valid signature. If the Assertion is
verified, the original Assertion is removed and the canonicalized
version is prepended to the Response. However, if there were
multiple assertions, the second assertion could end up first in the
list of Assertions, even if it was unsigned.
For example this:
<Response>
<!--
Response unsigned. According to SAML spec must check
assertion signature.
-->
<Assertion>
<Signature>
<!-- Correrctly signed assertion -->
</Signature>
</Assertion>
<Assertion>
<!-- Unsigned assertion inserted by attacker-->
</Assertion>
</Response>
could be verified then re-ordered to the following:
<Response>
<!--
Response unsigned. According to SAML spec must check
assertion signature.
-->
<Assertion>
<!-- Unsigned assertion inserted by attacker-->
</Assertion>
<Assertion>
<!-- Canonicalized, correrctly signed assertion -->
</Assertion>
</Response>
Fix this by removing all unverified child elements of the Response,
not just the original assertion.
* Improve Order of Namespace Declarations and Attributes in Canonical XML. This is related to an issue in goxmldsig for which I created an [pull request](https://github.com/russellhaering/goxmldsig/pull/17).
* Do not compress the AuthnRequest if `HTTP-POST` binding is used.
* SAML Response is valid if the Message and/or the Assertion is signed.
* Add `AssertionConsumerServiceURL` to `AuthnRequest`
* Validate Status on the Response
* Validate Conditions on the Assertion
* Validation SubjectConfirmation on the Subject
Specify "DN" as attribute name to return, but will only work if not present in ldap.Entry.Attributes
Use when full DN is stored in groupSearch's userAttr
ghodss/yaml converts from YAML to JSON before attempting to unmarshal.
This allows us to:
* Get the correct behavor when decoding base64'd []byte slices.
* Use *json.RawMessage.
* Not have to support extravagant YAML features.
* Let our structs use `json:` tags
Instead of throwing a 500 error if a user enters an invalid name,
display the same text box as if the user had entered the wrong
password.
NOTE: An invalid username now returns much quicker than an invalid
password. Consider adding an arbitrary sleep in the future if we
care about masking which was invalid.
Let the server handle the state token instead of the connector. As a
result it can throw out bad requests earlier. It can also use that
token to determine which connector was used to generate the request
allowing all connectors to share the same callback URL.
Callbacks now all look like:
https://dex.example.com/callback
Instead of:
https://dex.example.com/callback/(connector id)
Even when multiple connectors are being used.
Allow users to define config values which are read form environemnt
variables. Helpful for sensitive variables such as OAuth2 client IDs
or LDAP credentials.
Since we don't have a good strategy which takes a username and password
add a mock connector which implementes PasswordConnector so we can
develop the frontend screens.
