The filters for user and group searches hadn't been included in our LDAP
tests. Now they are.
The concrete test cases are somewhat contrived, but that shouldn't
matter too much. Also note that the example queries I've used are not
supported in AD: https://stackoverflow.com/a/10043452
Signed-off-by: Stephan Renatus <srenatus@chef.io>
For downstream apps using a github handle is much simpler than working
with numbers.
WHilst the number is stable and the handle is not - GitHUb does give you
a big scary wanring if you try and change it that bad things may happen
to you, and generally few users ever change it.
This can be enabled with a configuration option `useLoginAsId`
this will result in both the team name *and* the team slug being
returned for each team, allowing a bit more flexibility in auth
validation.
Signed-off-by: Topher Bullock <tbullock@pivotal.io>
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
Fixes#1304, if we want to be harsh.
However, I think if it was the user's intention to pass two certs, and
the second one couldn't be read, that shouldn't just disappear. After
all, when attempting to login later, that might fail because the
expected IdP cert data isn't there.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Format ldap.go
Format ldap.go: with a space for golint
with a space
Rename clientCA is to clientCert
Update ldap.go
modified the ldap client certificate file comments.
modified load ldap client cert error.
modified load ldap client cert error: fmt.Errorf("ldap: load client cert failed: %v", err)
Some directory servers (I think it's Oracle) return
Constraint Violation: Exceed password retry limit. Account locked.
when attempting to login too many times. While constraint violation can
mean many things, we're checking this as an error on BIND, so it's
more likely that something like this has happened than any other thing.
Hence, we should treat it as an "incorrect password" situation, not an
internal error.
It would of course be preferrable to surface more information about this
precise error (and similar ones), but I think this is beyond this small
change.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Microsoft connector now provides support for 'groups' claim in case
'tenant' is configured in Dex config for the connector. It's possible to
deny user authentication if the user is not a member of at least one
configured groups.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.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 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.
