Skip to content
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

Merged
merged 17 commits into from
Mar 30, 2019

Conversation

jkakavas
Copy link
Member

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.

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.
@jkakavas jkakavas added :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) v8.0.0 v7.2.0 labels Mar 20, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@jkakavas
Copy link
Member Author

@elasticmachine test this please

depends_on:
- openldap
ports:
- "8080:8080"
Copy link
Member

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.

Copy link
Member Author

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!

@jkakavas jkakavas requested review from bizybot and jaymode and removed request for bizybot March 27, 2019 08:33
Copy link
Contributor

@bizybot bizybot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thank you.

Copy link
Contributor

@alpar-t alpar-t left a 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.

x-pack/qa/oidc-op-tests/build.gradle Outdated Show resolved Hide resolved
task setupPorts {
dependsOn idpFixtureProject.postProcessFixture
doLast {
ephemeralPort = idpFixtureProject.postProcessFixture.ext."test.fixtures.oidc-provider.tcp.8080"
Copy link
Contributor

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

Copy link
Member Author

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?

Copy link
Member Author

@jkakavas jkakavas Mar 28, 2019

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 ?

@jkakavas jkakavas requested a review from alpar-t March 28, 2019 13:25
Copy link
Member

@jaymode jaymode left a 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?

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'
Copy link
Member

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

Copy link
Member Author

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();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return HttpClients.custom().build();
return HttpClients.createDefault();

@jkakavas
Copy link
Member Author

jkakavas commented Mar 28, 2019

I do not like the idea of checking in a web-app, ldapAuth.

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 (ldapAuth/WEB-INF/ldapAuth.properties) and since the authors of the image didn't make that configurable (like they did with override.properties for the c2id server ) I couldn't find a better way to do this.
What I have tried :

  • try and map only the file with
    - ./oidc/ldapAuth.properties:/c2id-server/tomcat/webapps/ldapauth/WEB-INF/ldapAuth.properties
    
    This doesn't work as when docker maps this, the /c2id-server/tomcat/webapps/ is not yet created ( Tomcat hasn't still deployed the webapp ) and this means that we get /c2id-server/tomcat/webapps/ldapauth that only contains /c2id-server/tomcat/webapps/ldapauth/WEB-INF/ldapAuth.properties and no deployed application - tomcat fails to deploy this.

Is this something we could provision and/or build a image with it already there and just override the configuration?

Yes I can build an image based on theirs and replace ldapAuth.properties in the Dockerfile. I tried to stay away from building the image at runtime (as @atorok mentioned this would be slower and thus not desirable in general ), but where would you see us hosting the docker image ?

@jaymode
Copy link
Member

jaymode commented Mar 28, 2019

Maybe there is a way to add a doLast on the postProcessFixture that calls docker cp?

@jkakavas
Copy link
Member Author

Maybe there is a way to add a doLast on the postProcessFixture that calls docker cp?

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 localhost:ephemeralPort/manager/text/reload?path=/ldapAuth

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.
@jkakavas
Copy link
Member Author

@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.

@jkakavas jkakavas requested a review from jaymode March 29, 2019 10:11
Copy link
Member

@jaymode jaymode left a 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

x-pack/qa/oidc-op-tests/build.gradle Outdated Show resolved Hide resolved
Copy link
Contributor

@alpar-t alpar-t left a 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

@jkakavas jkakavas merged commit 948aa39 into elastic:feature-oidc-realm Mar 30, 2019
@jkakavas jkakavas deleted the oidc-realm-IT branch March 30, 2019 09:33
jkakavas added a commit that referenced this pull request Apr 4, 2019
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
jkakavas added a commit to jkakavas/elasticsearch that referenced this pull request Apr 14, 2019
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
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
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
@colings86 colings86 added >non-issue >test Issues or PRs that are addressing/adding tests and removed >non-issue labels Jun 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) >test Issues or PRs that are addressing/adding tests v7.2.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants