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
