honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/x-pack/test/idp-fixture/docker-compose.yml

175 lines
9.1 KiB
YAML
Raw Normal View History

Oidc additional client auth types (#58708) (#62289) The OpenID Connect specification defines a number of ways for a client (RP) to authenticate itself to the OP when accessing the Token Endpoint. We currently only support `client_secret_basic`. This change introduces support for 2 additional authentication methods, namely `client_secret_post` (where the client credentials are passed in the body of the POST request to the OP) and `client_secret_jwt` where the client constructs a JWT and signs it using the the client secret as a key. Support for the above, and especially `client_secret_jwt` in our integration tests meant that the OP we use ( Connect2id server ) should be able to validate the JWT that we send it from the RP. Since we run the OP in docker and it listens on an ephemeral port we would have no way of knowing the port so that we can configure the ES running via the testcluster to know the "correct" Token Endpoint, and even if we did, this would not be the Token Endpoint URL that the OP would think it listens on. To alleviate this, we run an ES single node cluster in docker, alongside the OP so that we can configured it with the correct hostname and port within the docker network. Co-authored-by: Ioannis Kakavas <ioannis@elastic.co>
2020-09-16 00:29:09 -04:00
version: '3.7'
Replace Vagrant with Docker for idp-fixture (#39948) The change replaces the Vagrant box based fixture with a fixture based on docker compose and 2 docker images, one for an openldap server and one for a Shibboleth SAML Identity Provider. The configuration of both openldap and shibboleth is identical to the previous one, in order to minimize required changes in the tests
2019-03-12 17:54:23 -04:00
services:
Oidc additional client auth types (#58708) (#62289) The OpenID Connect specification defines a number of ways for a client (RP) to authenticate itself to the OP when accessing the Token Endpoint. We currently only support `client_secret_basic`. This change introduces support for 2 additional authentication methods, namely `client_secret_post` (where the client credentials are passed in the body of the POST request to the OP) and `client_secret_jwt` where the client constructs a JWT and signs it using the the client secret as a key. Support for the above, and especially `client_secret_jwt` in our integration tests meant that the OP we use ( Connect2id server ) should be able to validate the JWT that we send it from the RP. Since we run the OP in docker and it listens on an ephemeral port we would have no way of knowing the port so that we can configure the ES running via the testcluster to know the "correct" Token Endpoint, and even if we did, this would not be the Token Endpoint URL that the OP would think it listens on. To alleviate this, we run an ES single node cluster in docker, alongside the OP so that we can configured it with the correct hostname and port within the docker network. Co-authored-by: Ioannis Kakavas <ioannis@elastic.co>
2020-09-16 00:29:09 -04:00
elasticsearch-node:
image: elasticsearch:test
environment:
- node.name=elasticsearch-node
- cluster.initial_master_nodes=elasticsearch-node
- cluster.name=elasticsearch-node
- bootstrap.memory_lock=true
- network.publish_host=127.0.0.1
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
- path.repo=/tmp/es-repo
- node.attr.testattr=test
- cluster.routing.allocation.disk.watermark.low=1b
- cluster.routing.allocation.disk.watermark.high=1b
- cluster.routing.allocation.disk.watermark.flood_stage=1b
- node.store.allow_mmap=false
- xpack.license.self_generated.type=trial
- xpack.security.enabled=true
- xpack.security.http.ssl.enabled=true
- xpack.security.http.ssl.keystore.path=testnode.jks
- xpack.security.authc.token.enabled=true
- xpack.security.authc.realms.file.file.order=0
- xpack.security.authc.realms.native.native.order=1
- xpack.security.authc.realms.oidc.c2id.order=2
- xpack.security.authc.realms.oidc.c2id.op.issuer=http://oidc-provider:8080/c2id
- xpack.security.authc.realms.oidc.c2id.op.authorization_endpoint=http://oidc-provider:8080/c2id-login
- xpack.security.authc.realms.oidc.c2id.op.token_endpoint=http://oidc-provider:8080/c2id/token
- xpack.security.authc.realms.oidc.c2id.op.userinfo_endpoint=http://oidc-provider:8080/c2id/userinfo
- xpack.security.authc.realms.oidc.c2id.op.jwkset_path=op-jwks.json
- xpack.security.authc.realms.oidc.c2id.rp.redirect_uri=https://my.fantastic.rp/cb
- xpack.security.authc.realms.oidc.c2id.rp.client_id=https://my.elasticsearch.org/rp
- xpack.security.authc.realms.oidc.c2id.rp.response_type=code
- xpack.security.authc.realms.oidc.c2id.claims.principal=sub
- xpack.security.authc.realms.oidc.c2id.claims.name=name
- xpack.security.authc.realms.oidc.c2id.claims.mail=email
- xpack.security.authc.realms.oidc.c2id.claims.groups=groups
- xpack.security.authc.realms.oidc.c2id-implicit.order=3
- xpack.security.authc.realms.oidc.c2id-implicit.op.issuer=http://oidc-provider:8080/c2id
- xpack.security.authc.realms.oidc.c2id-implicit.op.authorization_endpoint=http://oidc-provider:8080/c2id-login
- xpack.security.authc.realms.oidc.c2id-implicit.op.token_endpoint=http://oidc-provider:8080/c2id/token
- xpack.security.authc.realms.oidc.c2id-implicit.op.userinfo_endpoint=http://oidc-provider:8080/c2id/userinfo
- xpack.security.authc.realms.oidc.c2id-implicit.op.jwkset_path=op-jwks.json
- xpack.security.authc.realms.oidc.c2id-implicit.rp.redirect_uri=https://my.fantastic.rp/cb
- xpack.security.authc.realms.oidc.c2id-implicit.rp.client_id=elasticsearch-rp
- xpack.security.authc.realms.oidc.c2id-implicit.rp.response_type=id_token token
- xpack.security.authc.realms.oidc.c2id-implicit.claims.principal=sub
- xpack.security.authc.realms.oidc.c2id-implicit.claims.name=name
- xpack.security.authc.realms.oidc.c2id-implicit.claims.mail=email
- xpack.security.authc.realms.oidc.c2id-implicit.claims.groups=groups
- xpack.security.authc.realms.oidc.c2id-proxy.order=4
- xpack.security.authc.realms.oidc.c2id-proxy.op.issuer=http://oidc-provider:8080/c2id
- xpack.security.authc.realms.oidc.c2id-proxy.op.authorization_endpoint=http://oidc-provider:8080/c2id-login
- xpack.security.authc.realms.oidc.c2id-proxy.op.token_endpoint=http://oidc-provider:8080/c2id/token
- xpack.security.authc.realms.oidc.c2id-proxy.op.userinfo_endpoint=http://oidc-provider:8080/c2id/userinfo
- xpack.security.authc.realms.oidc.c2id-proxy.op.jwkset_path=op-jwks.json
- xpack.security.authc.realms.oidc.c2id-proxy.rp.redirect_uri=https://my.fantastic.rp/cb
- xpack.security.authc.realms.oidc.c2id-proxy.rp.client_id=https://my.elasticsearch.org/rp
- xpack.security.authc.realms.oidc.c2id-proxy.rp.response_type=code
- xpack.security.authc.realms.oidc.c2id-proxy.claims.principal=sub
- xpack.security.authc.realms.oidc.c2id-proxy.claims.name=name
- xpack.security.authc.realms.oidc.c2id-proxy.claims.mail=email
- xpack.security.authc.realms.oidc.c2id-proxy.claims.groups=groups
- xpack.security.authc.realms.oidc.c2id-proxy.http.proxy.host=http-proxy
- xpack.security.authc.realms.oidc.c2id-proxy.http.proxy.port=8888
- xpack.security.authc.realms.oidc.c2id-post.order=5
- xpack.security.authc.realms.oidc.c2id-post.op.issuer=http://oidc-provider:8080/c2id
- xpack.security.authc.realms.oidc.c2id-post.op.authorization_endpoint=http://oidc-provider:8080/c2id-login
- xpack.security.authc.realms.oidc.c2id-post.op.token_endpoint=http://oidc-provider:8080/c2id/token
- xpack.security.authc.realms.oidc.c2id-post.op.userinfo_endpoint=http://oidc-provider:8080/c2id/userinfo
- xpack.security.authc.realms.oidc.c2id-post.op.jwkset_path=op-jwks.json
- xpack.security.authc.realms.oidc.c2id-post.rp.redirect_uri=https://my.fantastic.rp/cb
- xpack.security.authc.realms.oidc.c2id-post.rp.client_id=elasticsearch-post
- xpack.security.authc.realms.oidc.c2id-post.rp.client_auth_method=client_secret_post
- xpack.security.authc.realms.oidc.c2id-post.rp.response_type=code
- xpack.security.authc.realms.oidc.c2id-post.claims.principal=sub
- xpack.security.authc.realms.oidc.c2id-post.claims.name=name
- xpack.security.authc.realms.oidc.c2id-post.claims.mail=email
- xpack.security.authc.realms.oidc.c2id-post.claims.groups=groups
- xpack.security.authc.realms.oidc.c2id-jwt.order=6
- xpack.security.authc.realms.oidc.c2id-jwt.op.issuer=http://oidc-provider:8080/c2id
- xpack.security.authc.realms.oidc.c2id-jwt.op.authorization_endpoint=http://oidc-provider:8080/c2id-login
- xpack.security.authc.realms.oidc.c2id-jwt.op.token_endpoint=http://oidc-provider:8080/c2id/token
- xpack.security.authc.realms.oidc.c2id-jwt.op.userinfo_endpoint=http://oidc-provider:8080/c2id/userinfo
- xpack.security.authc.realms.oidc.c2id-jwt.op.jwkset_path=op-jwks.json
- xpack.security.authc.realms.oidc.c2id-jwt.rp.redirect_uri=https://my.fantastic.rp/cb
- xpack.security.authc.realms.oidc.c2id-jwt.rp.client_id=elasticsearch-post-jwt
- xpack.security.authc.realms.oidc.c2id-jwt.rp.client_auth_method=client_secret_jwt
- xpack.security.authc.realms.oidc.c2id-jwt.rp.response_type=code
- xpack.security.authc.realms.oidc.c2id-jwt.claims.principal=sub
- xpack.security.authc.realms.oidc.c2id-jwt.claims.name=name
- xpack.security.authc.realms.oidc.c2id-jwt.claims.mail=email
- xpack.security.authc.realms.oidc.c2id-jwt.claims.groups=groups
volumes:
- ./build/logs/node1:/usr/share/elasticsearch/logs
- ./build/certs/testnode.jks:/usr/share/elasticsearch/config/testnode.jks
- ./docker-test-entrypoint.sh:/docker-test-entrypoint.sh
- ./oidc/op-jwks.json:/usr/share/elasticsearch/config/op-jwks.json
ports:
- "9200"
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
entrypoint: /docker-test-entrypoint.sh
healthcheck:
start_period: 15s
test: ["CMD", "curl", "-f", "-u", "x_pack_rest_user:x-pack-test-password", "-k", "https://localhost:9200"]
interval: 10s
timeout: 2s
retries: 5
Replace Vagrant with Docker for idp-fixture (#39948) The change replaces the Vagrant box based fixture with a fixture based on docker compose and 2 docker images, one for an openldap server and one for a Shibboleth SAML Identity Provider. The configuration of both openldap and shibboleth is identical to the previous one, in order to minimize required changes in the tests
2019-03-12 17:54:23 -04:00
openldap:
command: --copy-service --loglevel debug
Oidc additional client auth types (#58708) (#62289) The OpenID Connect specification defines a number of ways for a client (RP) to authenticate itself to the OP when accessing the Token Endpoint. We currently only support `client_secret_basic`. This change introduces support for 2 additional authentication methods, namely `client_secret_post` (where the client credentials are passed in the body of the POST request to the OP) and `client_secret_jwt` where the client constructs a JWT and signs it using the the client secret as a key. Support for the above, and especially `client_secret_jwt` in our integration tests meant that the OP we use ( Connect2id server ) should be able to validate the JWT that we send it from the RP. Since we run the OP in docker and it listens on an ephemeral port we would have no way of knowing the port so that we can configure the ES running via the testcluster to know the "correct" Token Endpoint, and even if we did, this would not be the Token Endpoint URL that the OP would think it listens on. To alleviate this, we run an ES single node cluster in docker, alongside the OP so that we can configured it with the correct hostname and port within the docker network. Co-authored-by: Ioannis Kakavas <ioannis@elastic.co>
2020-09-16 00:29:09 -04:00
image: "osixia/openldap:1.4.0"
Replace Vagrant with Docker for idp-fixture (#39948) The change replaces the Vagrant box based fixture with a fixture based on docker compose and 2 docker images, one for an openldap server and one for a Shibboleth SAML Identity Provider. The configuration of both openldap and shibboleth is identical to the previous one, in order to minimize required changes in the tests
2019-03-12 17:54:23 -04:00
ports:
Use ephemeral ports for idp-fixture (#40333) This change removes the use of hardcoded port values for the idp-fixture in favor of the mapped ephemeral ports. This should prevent failures due to port conflicts in CI.
2019-03-26 10:40:00 -04:00
- "389"
- "636"
Replace Vagrant with Docker for idp-fixture (#39948) The change replaces the Vagrant box based fixture with a fixture based on docker compose and 2 docker images, one for an openldap server and one for a Shibboleth SAML Identity Provider. The configuration of both openldap and shibboleth is identical to the previous one, in order to minimize required changes in the tests
2019-03-12 17:54:23 -04:00
environment:
LDAP_ADMIN_PASSWORD: "NickFuryHeartsES"
LDAP_DOMAIN: "oldap.test.elasticsearch.com"
LDAP_BASE_DN: "DC=oldap,DC=test,DC=elasticsearch,DC=com"
LDAP_TLS: "true"
LDAP_TLS_CRT_FILENAME: "ldap_server.pem"
LDAP_TLS_CA_CRT_FILENAME: "ca_server.pem"
LDAP_TLS_KEY_FILENAME: "ldap_server.key"
LDAP_TLS_VERIFY_CLIENT: "never"
LDAP_TLS_CIPHER_SUITE: "NORMAL"
LDAP_LOG_LEVEL: 256
volumes:
- ./openldap/ldif/users.ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom/20-bootstrap-users.ldif
- ./openldap/ldif/config.ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom/10-bootstrap-config.ldif
- ./openldap/certs:/container/service/slapd/assets/certs
shibboleth-idp:
image: "unicon/shibboleth-idp:3.4.2"
depends_on:
- openldap
environment:
- JETTY_MAX_HEAP=64m
- JETTY_BROWSER_SSL_KEYSTORE_PASSWORD=secret
- JETTY_BACKCHANNEL_SSL_KEYSTORE_PASSWORD=secret
ports:
Use ephemeral ports for idp-fixture (#40333) This change removes the use of hardcoded port values for the idp-fixture in favor of the mapped ephemeral ports. This should prevent failures due to port conflicts in CI.
2019-03-26 10:40:00 -04:00
- "4443"
Replace Vagrant with Docker for idp-fixture (#39948) The change replaces the Vagrant box based fixture with a fixture based on docker compose and 2 docker images, one for an openldap server and one for a Shibboleth SAML Identity Provider. The configuration of both openldap and shibboleth is identical to the previous one, in order to minimize required changes in the tests
2019-03-12 17:54:23 -04:00
links:
- openldap:openldap
volumes:
- ./idp/shibboleth-idp/conf:/opt/shibboleth-idp/conf
- ./idp/shibboleth-idp/credentials:/opt/shibboleth-idp/credentials
Add SAML AuthN request signing tests (#61582) - Add a unit test for our signing code - Change SAML IT to use signed authentication requests for Shibboleth to consume Backport of #48444
2020-08-27 03:41:56 -04:00
- ./idp/shibboleth-idp/metadata:/opt/shibboleth-idp/metadata
Replace Vagrant with Docker for idp-fixture (#39948) The change replaces the Vagrant box based fixture with a fixture based on docker compose and 2 docker images, one for an openldap server and one for a Shibboleth SAML Identity Provider. The configuration of both openldap and shibboleth is identical to the previous one, in order to minimize required changes in the tests
2019-03-12 17:54:23 -04:00
- ./idp/shib-jetty-base/start.d/ssl.ini:/opt/shib-jetty-base/start.d/ssl.ini
Add an OpenID Connect authentication realm (#40674) (#41178) 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. This is a backport of #40674
2019-04-15 05:41:16 -04:00
oidc-provider:
Oidc additional client auth types (#58708) (#62289) The OpenID Connect specification defines a number of ways for a client (RP) to authenticate itself to the OP when accessing the Token Endpoint. We currently only support `client_secret_basic`. This change introduces support for 2 additional authentication methods, namely `client_secret_post` (where the client credentials are passed in the body of the POST request to the OP) and `client_secret_jwt` where the client constructs a JWT and signs it using the the client secret as a key. Support for the above, and especially `client_secret_jwt` in our integration tests meant that the OP we use ( Connect2id server ) should be able to validate the JWT that we send it from the RP. Since we run the OP in docker and it listens on an ephemeral port we would have no way of knowing the port so that we can configure the ES running via the testcluster to know the "correct" Token Endpoint, and even if we did, this would not be the Token Endpoint URL that the OP would think it listens on. To alleviate this, we run an ES single node cluster in docker, alongside the OP so that we can configured it with the correct hostname and port within the docker network. Co-authored-by: Ioannis Kakavas <ioannis@elastic.co>
2020-09-16 00:29:09 -04:00
image: "c2id/c2id-server:9.5"
[7.x] Add http proxy support for OIDC realm (#57039) (#57584) This change introduces support for using an http proxy for egress communication of the OpenID Connect realm.
2020-06-04 13:51:00 -04:00
depends_on:
- http-proxy
Add an OpenID Connect authentication realm (#40674) (#41178) 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. This is a backport of #40674
2019-04-15 05:41:16 -04:00
ports:
- "8080"
Oidc additional client auth types (#58708) (#62289) The OpenID Connect specification defines a number of ways for a client (RP) to authenticate itself to the OP when accessing the Token Endpoint. We currently only support `client_secret_basic`. This change introduces support for 2 additional authentication methods, namely `client_secret_post` (where the client credentials are passed in the body of the POST request to the OP) and `client_secret_jwt` where the client constructs a JWT and signs it using the the client secret as a key. Support for the above, and especially `client_secret_jwt` in our integration tests meant that the OP we use ( Connect2id server ) should be able to validate the JWT that we send it from the RP. Since we run the OP in docker and it listens on an ephemeral port we would have no way of knowing the port so that we can configure the ES running via the testcluster to know the "correct" Token Endpoint, and even if we did, this would not be the Token Endpoint URL that the OP would think it listens on. To alleviate this, we run an ES single node cluster in docker, alongside the OP so that we can configured it with the correct hostname and port within the docker network. Co-authored-by: Ioannis Kakavas <ioannis@elastic.co>
2020-09-16 00:29:09 -04:00
expose:
- "8080"
Add an OpenID Connect authentication realm (#40674) (#41178) 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. This is a backport of #40674
2019-04-15 05:41:16 -04:00
volumes:
[7.x] Add http proxy support for OIDC realm (#57039) (#57584) This change introduces support for using an http proxy for egress communication of the OpenID Connect realm.
2020-06-04 13:51:00 -04:00
- ./oidc/override.properties:/etc/c2id/override.properties
http-proxy:
image: "nginx:latest"
volumes:
- ./oidc/nginx.conf:/etc/nginx/nginx.conf
ports:
- "8888"
Oidc additional client auth types (#58708) (#62289) The OpenID Connect specification defines a number of ways for a client (RP) to authenticate itself to the OP when accessing the Token Endpoint. We currently only support `client_secret_basic`. This change introduces support for 2 additional authentication methods, namely `client_secret_post` (where the client credentials are passed in the body of the POST request to the OP) and `client_secret_jwt` where the client constructs a JWT and signs it using the the client secret as a key. Support for the above, and especially `client_secret_jwt` in our integration tests meant that the OP we use ( Connect2id server ) should be able to validate the JWT that we send it from the RP. Since we run the OP in docker and it listens on an ephemeral port we would have no way of knowing the port so that we can configure the ES running via the testcluster to know the "correct" Token Endpoint, and even if we did, this would not be the Token Endpoint URL that the OP would think it listens on. To alleviate this, we run an ES single node cluster in docker, alongside the OP so that we can configured it with the correct hostname and port within the docker network. Co-authored-by: Ioannis Kakavas <ioannis@elastic.co>
2020-09-16 00:29:09 -04:00
expose:
- "8888"