-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add OIDC authentication Integration Tests #40262
Conversation
This change introduces an OpenID Connect Provider in idp-fixture that uses the existing openldap server for authentication and as a user info repository. It also adds tests where a mock facilitator application (HttpClient) performs authentication using Elasticsearch's oidc realm against that OpenID Connect Provider, using both the authorization code and the implicit grant flows.
Pinging @elastic/es-security |
@elasticmachine test this please |
...ty/src/main/java/org/elasticsearch/xpack/security/authc/oidc/OpenIdConnectAuthenticator.java
Outdated
Show resolved
Hide resolved
depends_on: | ||
- openldap | ||
ports: | ||
- "8080:8080" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we avoid the hardcoded port? See #40333 for my suggestion on how to do it for the rest of the fixture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes! Will do :) I wasn't aware this could be handled this way, thanks!
...ty/src/main/java/org/elasticsearch/xpack/security/authc/oidc/OpenIdConnectAuthenticator.java
Outdated
Show resolved
Hide resolved
...-op-tests/src/test/java/org/elasticsearch/xpack/security/authc/oidc/OpenIdConnectAuthIT.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Thank you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some comments on the build side.
task setupPorts { | ||
dependsOn idpFixtureProject.postProcessFixture | ||
doLast { | ||
ephemeralPort = idpFixtureProject.postProcessFixture.ext."test.fixtures.oidc-provider.tcp.8080" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work on hosts without docker -Dtests.fixture.enabled=false
can be used to simulate it.
I think it also needs a fix from #40297
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I raised #40585 because I wasn't sure how to do this properly and will be integrating whatever solution we come up with here to. Did you mean something like https://github.com/elastic/elasticsearch/pull/40297/files#diff-4fbfb78d054fdb66e0b02f321c8d63c5R79?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work on hosts without docker
@atorok these kind of projects only contain integration tests that depend on systems running on Docker so could we have a generic way of "Don't even consider this project if Docker is not available" instead of simply disabling the integTest
task as I did in #40585 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not like the idea of checking in a web-app, ldapAuth
. Is this something we could provision and/or build a image with it already there and just override the configuration?
x-pack/qa/oidc-op-tests/build.gradle
Outdated
setting 'xpack.security.authc.realms.oidc.c2id-implicit.claims.name', 'name' | ||
setting 'xpack.security.authc.realms.oidc.c2id-implicit.claims.mail', 'email' | ||
// Allow for troubleshooting CI errors | ||
setting 'logger.org.elasticsearch.xpack.security.authc', 'TRACE' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you expecting this to fail in CI? I'd much rather leave this out because who knows what this could hide; maybe it slows things down enough that we miss a concurrency bug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you expecting this to fail in CI?
No :) , the idea was to have logs available for when it will - inevitably - fail . I see your point though, will remove this
} | ||
|
||
private CloseableHttpClient getHttpClient() { | ||
return HttpClients.custom().build(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return HttpClients.custom().build(); | |
return HttpClients.createDefault(); |
Well, we don't need to check the web app in - it is part of the image. The only reason we map this volume is so that we can replace the configuration of it (
Yes I can build an image based on theirs and replace |
Maybe there is a way to add a doLast on the postProcessFixture that calls |
That wouldn't work as ldapAuth would already be loaded by tomcat at that point and it doesn't reload config changes without restart. I'd need to see if the provided tomcat exposes its manager on 8080 and try and also do a curl to |
This change makes it so we use the internal test user (alice) of c2id image for testing. This in turn removes the need to configure ldapAuth and the dependency to openldap.
@jaymode I stopped using the ldapAuth application for our testing. What we care about in this context is the retrieved claims we get from the Provider, and not how the provider sourced them (internal file, ldap, etc) . This means we don't have to deal with the issue of configuring ldapAuth anymore. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left one question, otherwise LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a comment, other than that the build LGTM
This commit adds an OpenID Connect authentication realm to elasticsearch. Elasticsearch (with the assistance of kibana or another web component) acts as an OpenID Connect Relying Party and supports the Authorization Code Grant and Implicit flows as described in http://ela.st/oidc-spec. It adds support for consuming and verifying signed ID Tokens, both RP initiated and 3rd party initiated Single Sign on and RP initiated signle logout. It also adds an OpenID Connect Provider in the idp-fixture to be used for the associated integration tests. The code in this commit has been tracked in a feature branch and has been previously reviewed and approved in : #37009 #37787 #38474 #38475 #40262
This commit adds an OpenID Connect authentication realm to elasticsearch. Elasticsearch (with the assistance of kibana or another web component) acts as an OpenID Connect Relying Party and supports the Authorization Code Grant and Implicit flows as described in http://ela.st/oidc-spec. It adds support for consuming and verifying signed ID Tokens, both RP initiated and 3rd party initiated Single Sign on and RP initiated signle logout. It also adds an OpenID Connect Provider in the idp-fixture to be used for the associated integration tests. The code in this commit has been tracked in a feature branch and has been previously reviewed and approved in : elastic#37009 elastic#37787 elastic#38474 elastic#38475 elastic#40262
This commit adds an OpenID Connect authentication realm to elasticsearch. Elasticsearch (with the assistance of kibana or another web component) acts as an OpenID Connect Relying Party and supports the Authorization Code Grant and Implicit flows as described in http://ela.st/oidc-spec. It adds support for consuming and verifying signed ID Tokens, both RP initiated and 3rd party initiated Single Sign on and RP initiated signle logout. It also adds an OpenID Connect Provider in the idp-fixture to be used for the associated integration tests. The code in this commit has been tracked in a feature branch and has been previously reviewed and approved in : elastic#37009 elastic#37787 elastic#38474 elastic#38475 elastic#40262
This change introduces an OpenID Connect Provider in idp-fixture
that uses the existing openldap server for authentication and
as a user info repository.
It also adds tests where a mock facilitator application (HttpClient)
performs authentication using Elasticsearch's oidc realm against
that OpenID Connect Provider, using both the authorization code
and the implicit grant flows.