From 1a9a95945e83b065073d78fce414048b80bf3806 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 15:14:05 +0300 Subject: [PATCH 01/45] WIP --- .../configuring-pki-realm.asciidoc | 156 +++++++++++++----- 1 file changed, 118 insertions(+), 38 deletions(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 58144d0b23c1a..d7548442dc00a 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -2,26 +2,37 @@ [[configuring-pki-realm]] === Configuring a PKI realm -You can configure {es} to use Public Key Infrastructure (PKI) certificates -to authenticate users. This requires clients to present X.509 certificates. +You can configure {es} to use Public Key Infrastructure (PKI) certificates to +authenticate users. This requires clients connecting directly to {es} to +present X.509 certificates. The certificates must first be accepted for +authentication on the SSL/TLS layer on {es}, before they are optionally further +validated by a PKI realm. Users might also connect to {kib}, where they present +their certificate, but this requires a little extra configuration. On {es}, +this configuration enables {kib} to act as a proxy for SSL/TLS authentication +and submit the client certificates to {es} to be further validated by a PKI +realm. -NOTE: You cannot use PKI certificates to authenticate users in {kib}. +For more general information, see {stack-ov}/pki-realm.html[PKI User Authentication]. + +[float] +[role="xpack"] +[[pki-realm-for-direct-clients]] +==== PKI authentication for clients connecting directly to {es} To use PKI in {es}, you configure a PKI realm, enable client authentication on -the desired network layers (transport or http), and map the Distinguished Names -(DNs) from the user certificates to roles in the -<> or role-mapping file. +the desired network layers (transport or http), and map the Distinguished Name +(DN) from the Subject field in the user certificate to roles, using the +<> or the role-mapping file. You can also use a combination of PKI and username/password authentication. For example, you can enable SSL/TLS on the transport layer and define a PKI realm to require transport clients to authenticate with X.509 certificates, while still -authenticating HTTP traffic using username and password credentials. You can -also set `xpack.security.transport.ssl.client_authentication` to `optional` to +authenticating HTTP traffic using username and password credentials. You can +also set `xpack.security.transport.ssl.client_authentication` to `optional` to allow clients without certificates to authenticate with other credentials. -IMPORTANT: You must enable SSL/TLS and enable client authentication to use PKI. - -For more information, see {stack-ov}/pki-realm.html[PKI User Authentication]. +IMPORTANT: If you only allow PKI authentication for clients connecting directly +to {es}, you must enable SSL/TLS and enable client authentication. . Add a realm configuration for a `pki` realm to `elasticsearch.yml` under the `xpack.security.authc.realms.pki` namespace. @@ -43,17 +54,19 @@ xpack: order: 1 ------------------------------------------------------------ -With this configuration, any certificate trusted by the SSL/TLS layer is accepted -for authentication. The username is the common name (CN) extracted from the DN -of the certificate. +With this configuration, any certificate trusted by the {es} SSL/TLS layer is +accepted for authentication. The username is the common name (CN) extracted +from the DN in the Subject field of the end-entity certificate. This +configuration does not permit clients authenticating to {kib}. IMPORTANT: When you configure realms in `elasticsearch.yml`, only the realms you specify are used for authentication. If you also want to use the `native` or `file` realms, you must include them in the realm chain. -If you want to use something other than the CN of the DN as the username, you -can specify a regex to extract the desired username. For example, the regex in -the following configuration extracts the email address from the DN: +If you want to use something other than the CN of the Subject DN as the +username, you can specify a regex to extract the desired username. The regex is +applied on the Subject DN. For example, the regex in the following +configuration extracts the email address from the Subject DN: [source, yaml] ------------------------------------------------------------ @@ -65,22 +78,29 @@ xpack: pki1: username_pattern: "EMAILADDRESS=(.*?)(?:,|$)" ------------------------------------------------------------ + +NOTE: If the regex is too restrictive and does not match the Subject DN of the +client's certificate, then the realm will not authenticate the certificate. + -- -. Restart {es}. +. Restart {es} because realm configuration is not reloaded automatically. If +you're following through with the next steps, you might wish to hold the +restart for last. -. <>. +. <>. . Enable client authentication on the desired network layers (transport or http). + -- -The PKI realm relies on the TLS settings of the node's network interface. The -realm can be configured to be more restrictive than the underlying network -connection - that is, it is possible to configure the node such that some -connections are accepted by the network interface but then fail to be -authenticated by the PKI realm. However, the reverse is not possible. The PKI -realm cannot authenticate a connection that has been refused by the network +When clients connect directly to {es}, and are not proxy-authenticated by +{kib}, the PKI realm relies on the TLS settings of the node's network +interface. The realm can be configured to be more restrictive than the +underlying network connection - that is, it is possible to configure the node +such that some connections are accepted by the network interface but then fail +to be authenticated by the PKI realm. However, the reverse is not possible. The +PKI realm cannot authenticate a connection that has been refused by the network interface. In particular this means: @@ -96,14 +116,15 @@ In particular this means: used by the client. The relevant network interface (transport or http) must be configured to trust -any certificate that is to be used within the PKI realm. However, it possible to +any certificate that is to be used within the PKI realm. However, it is possible to configure the PKI realm to trust only a _subset_ of the certificates accepted by the network interface. This is useful when the SSL/TLS layer trusts clients with certificates that are signed by a different CA than the one that signs your users' certificates. -To configure the PKI realm with its own truststore, specify the `truststore.path` -option. For example: +To configure the PKI realm with its own truststore, specify the +`truststore.path` option. The path must be located within the Elasticsearch +configuration directory (ES_PATH_CONF). For example: [source, yaml] ------------------------------------------------------------ @@ -114,22 +135,33 @@ xpack: pki: pki1: truststore: - path: "/path/to/pki_truststore.jks" - password: "x-pack-test-password" + path: "ES_PATH_CONF/pki1_truststore.jks" +------------------------------------------------------------ + +If the truststore is password protected, the password should be configured by +adding the appropriate `secure_password` setting to the {es} keystore. For +example, the following command adds the password for the example realm above: + +[source, shell] +------------------------------------------------------------ +bin/elasticsearch-keystore add \ +xpack.security.authc.realms.pki.pki1.truststore.secure_password ------------------------------------------------------------ The `certificate_authorities` option can be used as an alternative to the -`truststore.path` setting. +`truststore.path` setting, when the certificate files are PEM formatted +(accepts a list). The two options are exclusive, they cannot be both used +simultaneously. -- . Map roles for PKI users. + -- -You map roles for PKI users through the -<> or by using a file stored on -each node. When a user authenticates against a PKI realm, the privileges for -that user are the union of all privileges defined by the roles to which the -user is mapped. +You map roles for PKI users through the <> or by using a file stored on each node. Configurations of both +options are merged together. When a user authenticates against a PKI realm, the +privileges for that user are the union of all privileges defined by the roles +to which the user is mapped. You identify a user by the distinguished name in their certificate. For example, the following mapping configuration maps `John Doe` to the @@ -150,7 +182,10 @@ PUT /_security/role_mapping/users // CONSOLE <1> The distinguished name (DN) of a PKI user. -Or, alternatively, configured in a role-mapping file: +Or, alternatively, configured inside a role-mapping file. The file's path +defaults to `ES_PATH_CONF/role_mapping.yml` but a different path, also inside +ES_PATH_CONF, may be specified by the realm setting `files.role_mapping` (e.g. +`xpack.security.authc.realms.pki.pki1.files.role_mapping`): [source, yaml] ------------------------------------------------------------ user: <1> @@ -163,7 +198,7 @@ The distinguished name for a PKI user follows X.500 naming conventions which place the most specific fields (like `cn` or `uid`) at the beginning of the name, and the most general fields (like `o` or `dc`) at the end of the name. Some tools, such as _openssl_, may print out the subject name in a different - format. +format. One way that you can determine the correct DN for a certificate is to use the <> (use the relevant PKI @@ -179,3 +214,48 @@ NOTE: The PKI realm supports alternative to role mapping. -- + +[float] +[role="xpack"] +[[pki-realm-for-proxied-clients]] +==== PKI authentication for clients connecting to {kib} + +Clients must normally connect directly to {es}, because the {es} PKI realm +relies on the node's network interface to do the SSL/TLS authentication and to +also internally forward the client's certificate chain for the realm to be able +to (optionally) validate it. If SSL/TLS authenticatication is to be performed +by {kib}, then the PKI realm must be configured to permit delegating it (and +the proxy must also support it). + +Specifically, when clients presenting X.509 certificates connect to {kib}, +{kib} will perform the SSL/TLS authentication and will forward the client's +certificate chain (calling an {es} API) to be further validated by PKI realms +configured for delegation. + +To permit authentication delegation for a specific {es} PKI realm, start by +configuring the realm for the usual case, as detailed in the +<> section, but making sure that you have explicitly configured +a `truststore` (or, equivalently `certificate_authorities`) even though it is +the same trust configuration that you have configured on the network layer. +Afterwards, simply toggle the `delegation.enabled` realm setting to `true`. +This realm is now allowed to validate delegated PKI authentication (after +restarting {es}). + +NOTE: PKI authentication delegation requires that +`xpack.security.authc.token.enabled` be `true`. + +NOTE: {kib} also needs to be configured to allow PKI certificate authentication. + +A PKI realm with `delegation.enabled` still works unchanged for clients +connecting directly to {es}. Directly authenticated users and users PKI +authenticated by {kib} indistinctly follow the same +{stack-ov}/mapping-roles.html[role mapping rules] or +{stack-ov}/realm-chains.html#authorization_realms[authorization realms +configurations]. If using the <>, +it is possible to distinguish between users authenticated by delegation from +users authenticated directly, because the former ones have the following two +extra metadata fields `pki_delegated_by_user` and `pki_delegated_by_realm`. +In the common setup, where authentication is delegated to {kib}, the values of +these fields are `kibana` and `reserved` respectively. + From 96ed13cf673ff5b0ffd85ca46878b90ea1bfd86c Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 16:20:30 +0300 Subject: [PATCH 02/45] configuring-pki-realm.asciidoc Completed --- .../configuring-pki-realm.asciidoc | 58 ++++++++++++++----- 1 file changed, 44 insertions(+), 14 deletions(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index d7548442dc00a..5d659b2232df5 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -7,10 +7,10 @@ authenticate users. This requires clients connecting directly to {es} to present X.509 certificates. The certificates must first be accepted for authentication on the SSL/TLS layer on {es}, before they are optionally further validated by a PKI realm. Users might also connect to {kib}, where they present -their certificate, but this requires a little extra configuration. On {es}, -this configuration enables {kib} to act as a proxy for SSL/TLS authentication -and submit the client certificates to {es} to be further validated by a PKI -realm. +their certificate, but this requires a little +<>. On {es}, this +configuration enables {kib} to act as a proxy for SSL/TLS authentication and +submit the client certificates to {es} to be further validated by a PKI realm. For more general information, see {stack-ov}/pki-realm.html[PKI User Authentication]. @@ -186,6 +186,7 @@ Or, alternatively, configured inside a role-mapping file. The file's path defaults to `ES_PATH_CONF/role_mapping.yml` but a different path, also inside ES_PATH_CONF, may be specified by the realm setting `files.role_mapping` (e.g. `xpack.security.authc.realms.pki.pki1.files.role_mapping`): + [source, yaml] ------------------------------------------------------------ user: <1> @@ -223,19 +224,18 @@ alternative to role mapping. Clients must normally connect directly to {es}, because the {es} PKI realm relies on the node's network interface to do the SSL/TLS authentication and to also internally forward the client's certificate chain for the realm to be able -to (optionally) validate it. If SSL/TLS authenticatication is to be performed -by {kib}, then the PKI realm must be configured to permit delegating it (and -the proxy must also support it). +to optionally validate it. If SSL/TLS authenticatication is to be performed +by {kib}, then the PKI realm must be configured to permit delegating it. Specifically, when clients presenting X.509 certificates connect to {kib}, {kib} will perform the SSL/TLS authentication and will forward the client's -certificate chain (calling an {es} API) to be further validated by PKI realms -configured for delegation. +certificate chain, by calling an {es} API, to have them further validated by +the PKI realms that have been configured for delegation. To permit authentication delegation for a specific {es} PKI realm, start by configuring the realm for the usual case, as detailed in the <> section, but making sure that you have explicitly configured +directly to {es}>> section, but make sure that you have explicitly configured a `truststore` (or, equivalently `certificate_authorities`) even though it is the same trust configuration that you have configured on the network layer. Afterwards, simply toggle the `delegation.enabled` realm setting to `true`. @@ -249,13 +249,43 @@ NOTE: {kib} also needs to be configured to allow PKI certificate authentication. A PKI realm with `delegation.enabled` still works unchanged for clients connecting directly to {es}. Directly authenticated users and users PKI -authenticated by {kib} indistinctly follow the same +authenticated by delegation to {kib} indistinctly follow the same {stack-ov}/mapping-roles.html[role mapping rules] or {stack-ov}/realm-chains.html#authorization_realms[authorization realms configurations]. If using the <>, it is possible to distinguish between users authenticated by delegation from users authenticated directly, because the former ones have the following two -extra metadata fields `pki_delegated_by_user` and `pki_delegated_by_realm`. -In the common setup, where authentication is delegated to {kib}, the values of -these fields are `kibana` and `reserved` respectively. +extra fields `pki_delegated_by_user` and `pki_delegated_by_realm` in the user's +metadata. In the common setup, where authentication is delegated to {kib}, the +values of these fields are `kibana` and `reserved`, respectively. For example, +the following role mapping rule: + +[source,js] +-------------------------------------------------- +PUT /_security/role_mapping/direct_pki_only +{ + "roles" : [ "role_for_pki1_direct" ], + "rules" : { + "all": [ + { + "field": {"realm.name": "pki1"} + }, + { + "except": { + "field": { + "metadata.pki_delegated_by_user": null <1> + } + } + } + ] + }, + "enabled": true +} +-------------------------------------------------- +// CONSOLE +<1> only when this metadata field is set (it is *not* `null`) the user has been +authenticated in the delegation scenario. +will assign the `role_for_pki1_direct` role to all users that have been +authenticated directly by the `pki1` realm, by connecting to {es} instead of +going through {kib}. From 91974748ad6f7cb84a4cce0cc2f1286fbc90e6a6 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 16:39:48 +0300 Subject: [PATCH 03/45] security-settings.asciidoc --- docs/reference/settings/security-settings.asciidoc | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/reference/settings/security-settings.asciidoc b/docs/reference/settings/security-settings.asciidoc index 486dbfc125832..abcd275facb54 100644 --- a/docs/reference/settings/security-settings.asciidoc +++ b/docs/reference/settings/security-settings.asciidoc @@ -864,10 +864,13 @@ Defaults to `100000`. `delegation.enabled`:: Generally, in order for the clients to be authenticated by the PKI realm they must connect directly to {es}. That is, they must not pass through proxies -which terminate the TLS connection. In order to allow for a *trusted* and +which terminate the TLS connection. In order to allow for a *trusted* and *smart* proxy, such as Kibana, to sit before {es} and terminate TLS connections, but still allow clients to be authenticated on {es} by this realm, -you need to toggle this to `true`. Defaults to `false`. +you need to toggle this to `true`. Defaults to `false`. This setting requires +the `truststore` or `certificate_authorities` be defined. For more details, see +<>. [[ref-saml-settings]] [float] From 9195c326d07318f471084ed20564b0747828c845 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 16:44:02 +0300 Subject: [PATCH 04/45] mapping-roles --- x-pack/docs/en/security/authorization/mapping-roles.asciidoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc index a99e385bd8c25..93918a7753d5c 100644 --- a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc +++ b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc @@ -28,6 +28,8 @@ you are able to map users to both API-managed roles and file-managed roles NOTE: The PKI, LDAP, Kerberos and SAML realms support using <> as an alternative to role mapping. +NOTE: Users with no roles assigned will be unauthorized for any action. + [[mapping-roles-api]] ==== Using the role mapping API From 383e3a53c03439b849753ab45c81325fd257034a Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 17:59:09 +0300 Subject: [PATCH 05/45] delegate-pki-authentication but no examples --- .../delegate-pki-authentication.asciidoc | 305 ++++++++++++++++++ 1 file changed, 305 insertions(+) create mode 100644 x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc diff --git a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc new file mode 100644 index 0000000000000..b51e4fef68c6b --- /dev/null +++ b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc @@ -0,0 +1,305 @@ +[role="xpack"] +[[security-api-delegate-pki-authentication]] +=== Delegate PKI authentication API +++++ +Delegate PKI authentication +++++ + +Implements the exchange of an {@code X509Certificate} chain into an {es} access +token. + +[[security-api-delegate-pki-authentication-request]] +==== {api-request-title} + +`POST /_security/delegate_pki` + +[[security-api-dellegate-pki-authentication-prereqs]] +==== {api-prereq-title} + +To use this API, you must have the `delegate_pki` or the `all` cluster privilege. +The `kibana_system` built-in role already grants this privilege. + +[[security-api-delegate-pki-authentication-desc]] +==== {api-description-title} + +Implements the exchange of an _X509Certificate_ chain into an {es} access +token. The certificate chain is validated according to RFC 5280, by +sequentially considering the trust configuration of every installed _PkiRealm_ +that has `delegation.enabled` set to `true` (default is `false`). A +successfully trusted client certificate is also subject to the validation of +the subject distinguished name according to that respective's realm +`username_pattern`. + +This API is called by *smart* and *trusted* proxies, such as {kib}, +that terminate the user's TLS session, and still wish to authenticate the user +by a PKI realm, as if the user connected directly to {es}. For more details, +see <>. + +IMPORTANT: The association between the subject public key in the target +certificate and the corresponding private key is *not* validated. This is part +of the TLS authentication process and it is delegated to the proxy calling this +API. The proxy is *trusted* to have performed the TLS authentication, and this +API translates that authentication into an {es} access token. + +[[security-api-delegate-pki-authentication-request-body]] +==== {api-request-body-title} + +The body of the POST request has a single parameter, which contains the +_X509Certificate_ chain. The certificate chain is represented as an array where +the first element is the target certificate containing the subject +distinguished name that is requesting access. This may be followed by +additional certificates, with each subsequent certificate being the one used to +certify the previous one. + +`x509_certificate_chain`:: +(Required, list of strings) The chain is represented as an ordered string +array. Each string in the array is a base64-encoded (Section 4 of RFC4648 - not +base64url-encoded) DER PKIX certificate value. + +[[security-api-delegate-pki-authentication-example]] +==== {api-examples-title} + +The following example assigns the "user" role to all users: + +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping1 +{ + "roles": [ "user"], + "enabled": true, <1> + "rules": { + "field" : { "username" : "*" } + }, + "metadata" : { <2> + "version" : 1 + } +} +------------------------------------------------------------ +// CONSOLE +<1> Mappings that have `enabled` set to `false` are ignored when role mapping + is performed. +<2> Metadata is optional. + +A successful call returns a JSON structure that shows whether the mapping has +been created or updated. + +[source,js] +-------------------------------------------------- +{ + "role_mapping" : { + "created" : true <1> + } +} +-------------------------------------------------- +// TESTRESPONSE +<1> When an existing mapping is updated, `created` is set to false. + +The following example assigns the "user" and "admin" roles to specific users: + +[source,js] +-------------------------------------------------- +POST /_security/role_mapping/mapping2 +{ + "roles": [ "user", "admin" ], + "enabled": true, + "rules": { + "field" : { "username" : [ "esadmin01", "esadmin02" ] } + } +} +-------------------------------------------------- +// CONSOLE + +The following example matches users who authenticated against a specific realm: +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping3 +{ + "roles": [ "ldap-user" ], + "enabled": true, + "rules": { + "field" : { "realm.name" : "ldap1" } + } +} +------------------------------------------------------------ +// CONSOLE + +The following example matches any user where either the username is `esadmin` +or the user is in the `cn=admin,dc=example,dc=com` group: + +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping4 +{ + "roles": [ "superuser" ], + "enabled": true, + "rules": { + "any": [ + { + "field": { + "username": "esadmin" + } + }, + { + "field": { + "groups": "cn=admins,dc=example,dc=com" + } + } + ] + } +} +------------------------------------------------------------ +// CONSOLE + +The example above is useful when the group names in your identity management +system (such as Active Directory, or a SAML Identity Provider) do not have a +1-to-1 correspondence with the names of roles in {es}. The role mapping is the +means by which you link a _group name_ with a _role name_. + +However, in rare cases the names of your groups may be an exact match for the +names of your {es} roles. This can be the case when your SAML Identity Provider +includes its own "group mapping" feature and can be configured to release {es} +role names in the user's SAML attributes. + +In these cases it is possible to use a template that treats the group names as +role names. + +*Note*: This should only be done if you intend to define roles for all of the +provided groups. Mapping a user to a large number of unnecessary or undefined +roles is inefficient and can have a negative effect on system performance. +If you only need to map a subset of the groups, then you should do this +using explicit mappings. + +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping5 +{ + "role_templates": [ + { + "template": { "source": "{{#tojson}}groups{{/tojson}}" }, <1> + "format" : "json" <2> + } + ], + "rules": { + "field" : { "realm.name" : "saml1" } + }, + "enabled": true +} +------------------------------------------------------------ +// CONSOLE +<1> The `tojson` mustache function is used to convert the list of + group names into a valid JSON array. +<2> Because the template produces a JSON array, the format must be + set to `json`. + +The following example matches users within a specific LDAP sub-tree: + +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping6 +{ + "roles": [ "example-user" ], + "enabled": true, + "rules": { + "field" : { "dn" : "*,ou=subtree,dc=example,dc=com" } + } +} +------------------------------------------------------------ +// CONSOLE + +The following example matches users within a particular LDAP sub-tree in a +specific realm: + +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping7 +{ + "roles": [ "ldap-example-user" ], + "enabled": true, + "rules": { + "all": [ + { "field" : { "dn" : "*,ou=subtree,dc=example,dc=com" } }, + { "field" : { "realm.name" : "ldap1" } } + ] + } +} +------------------------------------------------------------ +// CONSOLE + +The rules can be more complex and include wildcard matching. For example, the +following mapping matches any user where *all* of these conditions are met: + +- the _Distinguished Name_ matches the pattern `*,ou=admin,dc=example,dc=com`, + or the username is `es-admin`, or the username is `es-system` +- the user in in the `cn=people,dc=example,dc=com` group +- the user does not have a `terminated_date` + + +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping8 +{ + "roles": [ "superuser" ], + "enabled": true, + "rules": { + "all": [ + { + "any": [ + { + "field": { + "dn": "*,ou=admin,dc=example,dc=com" + } + }, + { + "field": { + "username": [ "es-admin", "es-system" ] + } + } + ] + }, + { + "field": { + "groups": "cn=people,dc=example,dc=com" + } + }, + { + "except": { + "field": { + "metadata.terminated_date": null + } + } + } + ] + } +} +------------------------------------------------------------ +// CONSOLE + +A templated role can be used to automatically map every user to their own +custom role. The role itself can be defined through the +<> or using a +{stack-ov}/custom-roles-authorization.html#implementing-custom-roles-provider[custom roles provider]. + +In this example every user who authenticates using the "cloud-saml" realm +will be automatically mapped to two roles - the `"saml_user"` role and a +role that is their username prefixed with `_user_`. +As an example, the user `nwong` would be assigned the `saml_user` and +`_user_nwong` roles. + +[source, js] +------------------------------------------------------------ +POST /_security/role_mapping/mapping9 +{ + "rules": { "field": { "realm.name": "cloud-saml" } }, + "role_templates": [ + { "template": { "source" : "saml_user" } }, <1> + { "template": { "source" : "_user_{{username}}" } } + ], + "enabled": true +} +------------------------------------------------------------ +// CONSOLE +<1> Because it is not possible to specify both `roles` and `role_templates` in + the same role mapping, we can apply a "fixed name" role by using a template + that has no substitutions. + From 69de90a45d9539b2ed8fa4aba2109735266874b3 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 21:18:16 +0300 Subject: [PATCH 06/45] delegate-pki-authentication.asciidoc --- x-pack/docs/build.gradle | 4 + .../delegate-pki-authentication.asciidoc | 241 +----------------- 2 files changed, 15 insertions(+), 230 deletions(-) diff --git a/x-pack/docs/build.gradle b/x-pack/docs/build.gradle index fe07450bbc10e..df4a318e1ffd2 100644 --- a/x-pack/docs/build.gradle +++ b/x-pack/docs/build.gradle @@ -34,6 +34,7 @@ project.copyRestSpec.from(xpackResources) { testClusters.integTest { extraConfigFile 'op-jwks.json', xpackProject('test:idp-fixture').file("oidc/op-jwks.json") + extraConfigFile 'testClient.crt', xpackProject('plugin:security').file("src/test/resources/org/elasticsearch/xpack/security/action/pki_delegation/testClient.crt") setting 'xpack.security.enabled', 'true' setting 'xpack.security.authc.api_key.enabled', 'true' setting 'xpack.security.authc.token.enabled', 'true' @@ -53,6 +54,9 @@ testClusters.integTest { keystore 'xpack.security.authc.realms.oidc.oidc1.rp.client_secret', 'b07efb7a1cf6ec9462afe7b6d3ab55c6c7880262aa61ac28dded292aca47c9a2' setting 'xpack.security.authc.realms.oidc.oidc1.rp.response_type', 'id_token' setting 'xpack.security.authc.realms.oidc.oidc1.claims.principal', 'sub' + setting 'xpack.security.authc.realms.pki.pki1.order', '3' + setting 'xpack.security.authc.realms.pki.pki1.certificate_authorities', '[ "testClient.crt" ]' + setting 'xpack.security.authc.realms.pki.pki1.delegation.enabled', 'true' user username: 'test_admin' } diff --git a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc index b51e4fef68c6b..80b242702f21e 100644 --- a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc +++ b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc @@ -50,7 +50,8 @@ _X509Certificate_ chain. The certificate chain is represented as an array where the first element is the target certificate containing the subject distinguished name that is requesting access. This may be followed by additional certificates, with each subsequent certificate being the one used to -certify the previous one. +certify the previous one. The response is an access token for the Subject DN +of the client's certificate. `x509_certificate_chain`:: (Required, list of strings) The chain is represented as an ordered string @@ -60,246 +61,26 @@ base64url-encoded) DER PKIX certificate value. [[security-api-delegate-pki-authentication-example]] ==== {api-examples-title} -The following example assigns the "user" role to all users: +The following is an example request: [source, js] ------------------------------------------------------------ -POST /_security/role_mapping/mapping1 +POST /_security/delegate_pki { - "roles": [ "user"], - "enabled": true, <1> - "rules": { - "field" : { "username" : "*" } - }, - "metadata" : { <2> - "version" : 1 - } + "x509_certificate_chain": ["MIIDbTCCAlWgAwIBAgIJAIxTS7Qdho9jMA0GCSqGSIb3DQEBCwUAMFMxKzApBgNVBAMTIkVsYXN0aWNzZWFyY2ggVGVzdCBJbnRlcm1lZGlhdGUgQ0ExFjAUBgNVBAsTDUVsYXN0aWNzZWFyY2gxDDAKBgNVBAoTA29yZzAeFw0xOTA3MTkxMzMzNDFaFw0yMzA3MTgxMzMzNDFaMEoxIjAgBgNVBAMTGUVsYXN0aWNzZWFyY2ggVGVzdCBDbGllbnQxFjAUBgNVBAsTDUVsYXN0aWNzZWFyY2gxDDAKBgNVBAoTA29yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANHgMX2aX8t0nj4sGLNuKISmmXIYCj9RwRqS7L03l9Nng7kOKnhHu/nXDt7zMRJyHj+q6FAt5khlavYSVCQyrDybRuA5z31gOdqXerrjs2OXS5HSHNvoDAnHFsaYX/5geMewVTtc/vqpd7Ph/QtaKfmG2FK0JNQo0k24tcgCIcyMtBh6BA70yGBM0OT8GdOgd/d/mA7mRhaxIUMNYQzRYRsp4hMnnWoOTkR5Q8KSO3MKw9dPSpPe8EnwtJE10S3s5aXmgytru/xQqrFycPBNj4KbKVmqMP0G60CzXik5pr2LNvOFz3Qb6sYJtqeZF+JKgGWdaTC89m63+TEnUHqk0lcCAwEAAaNNMEswCQYDVR0TBAIwADAdBgNVHQ4EFgQU/+aAD6Q4mFq1vpHorC25/OY5zjcwHwYDVR0jBBgwFoAU8siFCiMiYZZm/95qFC75AG/LRE0wDQYJKoZIhvcNAQELBQADggEBAIRpCgDLpvXcgDHUk10uhxev21mlIbU+VP46ANnCuj0UELhTrdTuWvO1PAI4z+WbDUxryQfOOXO9R6D0dE5yR56L/J7d+KayW34zU7yRDZM7+rXpocdQ1Ex8mjP9HJ/Bf56YZTBQJpXeDrKow4FvtkI3bcIMkqmbG16LHQXeG3RS4ds4S4wCnE2nA6vIn9y+4R999q6y1VSBORrYULcDWxS54plHLEdiMr1vVallg82AGobS9GMcTL2U4Nx5IYZG7sbTk3LrDxVpVg/S2wLofEdOEwqCeHug/iOihNLJBabEW6z4TDLJAVW5KCY1DfhkYlBfHn7vxKkfKoCUK/yLWWI="] <1> } ------------------------------------------------------------ // CONSOLE -<1> Mappings that have `enabled` set to `false` are ignored when role mapping - is performed. -<2> Metadata is optional. +<1> A one element certificate chain. -A successful call returns a JSON structure that shows whether the mapping has -been created or updated. +Which returns the following response: [source,js] -------------------------------------------------- { - "role_mapping" : { - "created" : true <1> - } + "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==", + "type" : "Bearer", + "expires_in" : 1200 } -------------------------------------------------- -// TESTRESPONSE -<1> When an existing mapping is updated, `created` is set to false. - -The following example assigns the "user" and "admin" roles to specific users: - -[source,js] --------------------------------------------------- -POST /_security/role_mapping/mapping2 -{ - "roles": [ "user", "admin" ], - "enabled": true, - "rules": { - "field" : { "username" : [ "esadmin01", "esadmin02" ] } - } -} --------------------------------------------------- -// CONSOLE - -The following example matches users who authenticated against a specific realm: -[source, js] ------------------------------------------------------------- -POST /_security/role_mapping/mapping3 -{ - "roles": [ "ldap-user" ], - "enabled": true, - "rules": { - "field" : { "realm.name" : "ldap1" } - } -} ------------------------------------------------------------- -// CONSOLE - -The following example matches any user where either the username is `esadmin` -or the user is in the `cn=admin,dc=example,dc=com` group: - -[source, js] ------------------------------------------------------------- -POST /_security/role_mapping/mapping4 -{ - "roles": [ "superuser" ], - "enabled": true, - "rules": { - "any": [ - { - "field": { - "username": "esadmin" - } - }, - { - "field": { - "groups": "cn=admins,dc=example,dc=com" - } - } - ] - } -} ------------------------------------------------------------- -// CONSOLE - -The example above is useful when the group names in your identity management -system (such as Active Directory, or a SAML Identity Provider) do not have a -1-to-1 correspondence with the names of roles in {es}. The role mapping is the -means by which you link a _group name_ with a _role name_. - -However, in rare cases the names of your groups may be an exact match for the -names of your {es} roles. This can be the case when your SAML Identity Provider -includes its own "group mapping" feature and can be configured to release {es} -role names in the user's SAML attributes. - -In these cases it is possible to use a template that treats the group names as -role names. - -*Note*: This should only be done if you intend to define roles for all of the -provided groups. Mapping a user to a large number of unnecessary or undefined -roles is inefficient and can have a negative effect on system performance. -If you only need to map a subset of the groups, then you should do this -using explicit mappings. - -[source, js] ------------------------------------------------------------- -POST /_security/role_mapping/mapping5 -{ - "role_templates": [ - { - "template": { "source": "{{#tojson}}groups{{/tojson}}" }, <1> - "format" : "json" <2> - } - ], - "rules": { - "field" : { "realm.name" : "saml1" } - }, - "enabled": true -} ------------------------------------------------------------- -// CONSOLE -<1> The `tojson` mustache function is used to convert the list of - group names into a valid JSON array. -<2> Because the template produces a JSON array, the format must be - set to `json`. - -The following example matches users within a specific LDAP sub-tree: - -[source, js] ------------------------------------------------------------- -POST /_security/role_mapping/mapping6 -{ - "roles": [ "example-user" ], - "enabled": true, - "rules": { - "field" : { "dn" : "*,ou=subtree,dc=example,dc=com" } - } -} ------------------------------------------------------------- -// CONSOLE - -The following example matches users within a particular LDAP sub-tree in a -specific realm: - -[source, js] ------------------------------------------------------------- -POST /_security/role_mapping/mapping7 -{ - "roles": [ "ldap-example-user" ], - "enabled": true, - "rules": { - "all": [ - { "field" : { "dn" : "*,ou=subtree,dc=example,dc=com" } }, - { "field" : { "realm.name" : "ldap1" } } - ] - } -} ------------------------------------------------------------- -// CONSOLE - -The rules can be more complex and include wildcard matching. For example, the -following mapping matches any user where *all* of these conditions are met: - -- the _Distinguished Name_ matches the pattern `*,ou=admin,dc=example,dc=com`, - or the username is `es-admin`, or the username is `es-system` -- the user in in the `cn=people,dc=example,dc=com` group -- the user does not have a `terminated_date` - - -[source, js] ------------------------------------------------------------- -POST /_security/role_mapping/mapping8 -{ - "roles": [ "superuser" ], - "enabled": true, - "rules": { - "all": [ - { - "any": [ - { - "field": { - "dn": "*,ou=admin,dc=example,dc=com" - } - }, - { - "field": { - "username": [ "es-admin", "es-system" ] - } - } - ] - }, - { - "field": { - "groups": "cn=people,dc=example,dc=com" - } - }, - { - "except": { - "field": { - "metadata.terminated_date": null - } - } - } - ] - } -} ------------------------------------------------------------- -// CONSOLE - -A templated role can be used to automatically map every user to their own -custom role. The role itself can be defined through the -<> or using a -{stack-ov}/custom-roles-authorization.html#implementing-custom-roles-provider[custom roles provider]. - -In this example every user who authenticates using the "cloud-saml" realm -will be automatically mapped to two roles - the `"saml_user"` role and a -role that is their username prefixed with `_user_`. -As an example, the user `nwong` would be assigned the `saml_user` and -`_user_nwong` roles. - -[source, js] ------------------------------------------------------------- -POST /_security/role_mapping/mapping9 -{ - "rules": { "field": { "realm.name": "cloud-saml" } }, - "role_templates": [ - { "template": { "source" : "saml_user" } }, <1> - { "template": { "source" : "_user_{{username}}" } } - ], - "enabled": true -} ------------------------------------------------------------- -// CONSOLE -<1> Because it is not possible to specify both `roles` and `role_templates` in - the same role mapping, we can apply a "fixed name" role by using a template - that has no substitutions. - +// TESTRESPONSE[s/dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==/$body.access_token/] From c52484fc364dd7f43132b2d922478ed909f37d8f Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 22:54:26 +0300 Subject: [PATCH 07/45] Nits --- .../settings/security-settings.asciidoc | 6 +++--- .../delegate-pki-authentication.asciidoc | 17 +++++++++-------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/docs/reference/settings/security-settings.asciidoc b/docs/reference/settings/security-settings.asciidoc index abcd275facb54..4fed27cf1f683 100644 --- a/docs/reference/settings/security-settings.asciidoc +++ b/docs/reference/settings/security-settings.asciidoc @@ -868,9 +868,9 @@ which terminate the TLS connection. In order to allow for a *trusted* and *smart* proxy, such as Kibana, to sit before {es} and terminate TLS connections, but still allow clients to be authenticated on {es} by this realm, you need to toggle this to `true`. Defaults to `false`. This setting requires -the `truststore` or `certificate_authorities` be defined. For more details, see -<>. +that the `truststore` or `certificate_authorities` settings be defined as well. +For more details, see <>. [[ref-saml-settings]] [float] diff --git a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc index 80b242702f21e..f5f476aa9aef4 100644 --- a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc +++ b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc @@ -16,15 +16,16 @@ token. [[security-api-dellegate-pki-authentication-prereqs]] ==== {api-prereq-title} -To use this API, you must have the `delegate_pki` or the `all` cluster privilege. -The `kibana_system` built-in role already grants this privilege. +To call this API, the (proxy) user must have the `delegate_pki` or the `all` +cluster privileges. The `kibana_system` built-in role already grants this +privilege. [[security-api-delegate-pki-authentication-desc]] ==== {api-description-title} Implements the exchange of an _X509Certificate_ chain into an {es} access token. The certificate chain is validated according to RFC 5280, by -sequentially considering the trust configuration of every installed _PkiRealm_ +sequentially considering the trust configuration of every installed PKI realm that has `delegation.enabled` set to `true` (default is `false`). A successfully trusted client certificate is also subject to the validation of the subject distinguished name according to that respective's realm @@ -47,11 +48,11 @@ API translates that authentication into an {es} access token. The body of the POST request has a single parameter, which contains the _X509Certificate_ chain. The certificate chain is represented as an array where -the first element is the target certificate containing the subject -distinguished name that is requesting access. This may be followed by -additional certificates, with each subsequent certificate being the one used to -certify the previous one. The response is an access token for the Subject DN -of the client's certificate. +the first element is the target certificate contains the subject distinguished +name that is requesting access. This may be followed by additional +certificates, with each subsequent certificate being the one used to certify +the previous one. The response contains an access token associated to the +subject distinguished name of the client's certificate. `x509_certificate_chain`:: (Required, list of strings) The chain is represented as an ordered string From 3dd02cda0a93674151ca4c5f846fd6ac29eb2237 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 6 Aug 2019 23:20:56 +0300 Subject: [PATCH 08/45] Nit --- docs/reference/settings/security-settings.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/reference/settings/security-settings.asciidoc b/docs/reference/settings/security-settings.asciidoc index 4fed27cf1f683..1d4051718f1a0 100644 --- a/docs/reference/settings/security-settings.asciidoc +++ b/docs/reference/settings/security-settings.asciidoc @@ -868,8 +868,8 @@ which terminate the TLS connection. In order to allow for a *trusted* and *smart* proxy, such as Kibana, to sit before {es} and terminate TLS connections, but still allow clients to be authenticated on {es} by this realm, you need to toggle this to `true`. Defaults to `false`. This setting requires -that the `truststore` or `certificate_authorities` settings be defined as well. -For more details, see <>. [[ref-saml-settings]] From ee190ef6701c8442d2b2b31eb904c4452d98bd60 Mon Sep 17 00:00:00 2001 From: lcawl Date: Wed, 7 Aug 2019 17:51:38 -0700 Subject: [PATCH 09/45] [DOCS] Adds delete PKI authentication API to ES Reference --- x-pack/docs/en/rest-api/security.asciidoc | 2 + .../delegate-pki-authentication.asciidoc | 57 +++++++++++-------- 2 files changed, 35 insertions(+), 24 deletions(-) diff --git a/x-pack/docs/en/rest-api/security.asciidoc b/x-pack/docs/en/rest-api/security.asciidoc index 059dbc1e74716..d385ef29c4672 100644 --- a/x-pack/docs/en/rest-api/security.asciidoc +++ b/x-pack/docs/en/rest-api/security.asciidoc @@ -6,6 +6,7 @@ You can use the following APIs to perform security activities. * <> * <> +* <> * <> * <> * <> @@ -98,6 +99,7 @@ include::security/put-app-privileges.asciidoc[] include::security/create-role-mappings.asciidoc[] include::security/create-roles.asciidoc[] include::security/create-users.asciidoc[] +include::security/delegate-pki-authentication.asciidoc[] include::security/delete-app-privileges.asciidoc[] include::security/delete-role-mappings.asciidoc[] include::security/delete-roles.asciidoc[] diff --git a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc index f5f476aa9aef4..edfa30dd67b77 100644 --- a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc +++ b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc @@ -16,48 +16,57 @@ token. [[security-api-dellegate-pki-authentication-prereqs]] ==== {api-prereq-title} -To call this API, the (proxy) user must have the `delegate_pki` or the `all` -cluster privileges. The `kibana_system` built-in role already grants this -privilege. +* To call this API, the (proxy) user must have the `delegate_pki` or the `all` +cluster privilege. The `kibana_system` built-in role already grants this +privilege. See {stack-ov}/security-privileges.html[Security privileges]. [[security-api-delegate-pki-authentication-desc]] ==== {api-description-title} -Implements the exchange of an _X509Certificate_ chain into an {es} access -token. The certificate chain is validated according to RFC 5280, by +This API implements the exchange of an _X509Certificate_ chain for an {es} +access token. The certificate chain is validated, according to RFC 5280, by sequentially considering the trust configuration of every installed PKI realm that has `delegation.enabled` set to `true` (default is `false`). A successfully trusted client certificate is also subject to the validation of the subject distinguished name according to that respective's realm `username_pattern`. -This API is called by *smart* and *trusted* proxies, such as {kib}, -that terminate the user's TLS session, and still wish to authenticate the user -by a PKI realm, as if the user connected directly to {es}. For more details, -see <>. +This API is called by *smart* and *trusted* proxies, such as {kib}, which +terminate the user's TLS session but still want to authenticate the user +by using a PKI realm--as if the user connected directly to {es}. For more +details, see <>. IMPORTANT: The association between the subject public key in the target certificate and the corresponding private key is *not* validated. This is part -of the TLS authentication process and it is delegated to the proxy calling this -API. The proxy is *trusted* to have performed the TLS authentication, and this -API translates that authentication into an {es} access token. +of the TLS authentication process and it is delegated to the proxy that calls +this API. The proxy is *trusted* to have performed the TLS authentication and +this API translates that authentication into an {es} access token. [[security-api-delegate-pki-authentication-request-body]] ==== {api-request-body-title} -The body of the POST request has a single parameter, which contains the -_X509Certificate_ chain. The certificate chain is represented as an array where -the first element is the target certificate contains the subject distinguished -name that is requesting access. This may be followed by additional -certificates, with each subsequent certificate being the one used to certify -the previous one. The response contains an access token associated to the -subject distinguished name of the client's certificate. - `x509_certificate_chain`:: -(Required, list of strings) The chain is represented as an ordered string -array. Each string in the array is a base64-encoded (Section 4 of RFC4648 - not -base64url-encoded) DER PKIX certificate value. +(Required, list of strings) The _X509Certificate_ chain, which is represented as +an ordered string array. Each string in the array is a base64-encoded +(Section 4 of RFC4648 - not base64url-encoded) DER PKIX certificate value. ++ +The first element is the target certificate contains the subject distinguished +name that is requesting access. This may be followed by additional certificates; +each subsequent certificate is used to certify the previous one. + + +[[security-api-delegate-pki-authentication-response-body]] +==== {api-response-body-title} + +`access_token`:: +(string) An access token associated to the subject distinguished name of the +client's certificate. + +`expires_in`:: +(time units) The amount of time (in seconds) that the token expires in. + +`type`:: +(string) The type of token. [[security-api-delegate-pki-authentication-example]] ==== {api-examples-title} From 789611fb2abc593131a6460cb4ed1dea2039286d Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:07:21 +0300 Subject: [PATCH 10/45] Review --- .../configuring-pki-realm.asciidoc | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 5d659b2232df5..b8aafe15cde8c 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -5,9 +5,9 @@ You can configure {es} to use Public Key Infrastructure (PKI) certificates to authenticate users. This requires clients connecting directly to {es} to present X.509 certificates. The certificates must first be accepted for -authentication on the SSL/TLS layer on {es}, before they are optionally further -validated by a PKI realm. Users might also connect to {kib}, where they present -their certificate, but this requires a little +authentication on the SSL/TLS layer on {es}. Only then they are optionally +further validated by a PKI realm. Users might also connect to {kib} and +present their certificate, but this requires a little <>. On {es}, this configuration enables {kib} to act as a proxy for SSL/TLS authentication and submit the client certificates to {es} to be further validated by a PKI realm. @@ -31,8 +31,9 @@ authenticating HTTP traffic using username and password credentials. You can also set `xpack.security.transport.ssl.client_authentication` to `optional` to allow clients without certificates to authenticate with other credentials. -IMPORTANT: If you only allow PKI authentication for clients connecting directly -to {es}, you must enable SSL/TLS and enable client authentication. +IMPORTANT: You must enable SSL/TLS and enable client authentication, if you +only allow PKI authentication for clients connecting directly to {es}, but not +through {kib}. . Add a realm configuration for a `pki` realm to `elasticsearch.yml` under the `xpack.security.authc.realms.pki` namespace. @@ -80,7 +81,7 @@ xpack: ------------------------------------------------------------ NOTE: If the regex is too restrictive and does not match the Subject DN of the -client's certificate, then the realm will not authenticate the certificate. +client's certificate, then the realm does not authenticate the certificate. -- @@ -258,7 +259,9 @@ users authenticated directly, because the former ones have the following two extra fields `pki_delegated_by_user` and `pki_delegated_by_realm` in the user's metadata. In the common setup, where authentication is delegated to {kib}, the values of these fields are `kibana` and `reserved`, respectively. For example, -the following role mapping rule: +the following role mapping rule will assign the `role_for_pki1_direct` role to +all users that have been authenticated directly by the `pki1` realm, by +connecting to {es} instead of going through {kib}: [source,js] -------------------------------------------------- @@ -286,6 +289,3 @@ PUT /_security/role_mapping/direct_pki_only <1> only when this metadata field is set (it is *not* `null`) the user has been authenticated in the delegation scenario. -will assign the `role_for_pki1_direct` role to all users that have been -authenticated directly by the `pki1` realm, by connecting to {es} instead of -going through {kib}. From 5a0ef4d63a1d3de5a9384bea41280f64e2e2de47 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:08:45 +0300 Subject: [PATCH 11/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index b8aafe15cde8c..ca085c8799360 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -10,7 +10,7 @@ further validated by a PKI realm. Users might also connect to {kib} and present their certificate, but this requires a little <>. On {es}, this configuration enables {kib} to act as a proxy for SSL/TLS authentication and -submit the client certificates to {es} to be further validated by a PKI realm. +to submit the client certificates to {es} for further validation by a PKI realm. For more general information, see {stack-ov}/pki-realm.html[PKI User Authentication]. From a4e9e0626af35745b99db9aee0a62e3f26338094 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:08:56 +0300 Subject: [PATCH 12/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index ca085c8799360..4ea5e60b3c476 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -12,7 +12,7 @@ present their certificate, but this requires a little configuration enables {kib} to act as a proxy for SSL/TLS authentication and to submit the client certificates to {es} for further validation by a PKI realm. -For more general information, see {stack-ov}/pki-realm.html[PKI User Authentication]. +For more general information, see {stack-ov}/pki-realm.html[PKI user authentication]. [float] [role="xpack"] From af3693b34a9d6cc81e27de0ac4d9ad7394a82ac4 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:09:08 +0300 Subject: [PATCH 13/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 4ea5e60b3c476..852dac9a55045 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -21,7 +21,7 @@ For more general information, see {stack-ov}/pki-realm.html[PKI user authenticat To use PKI in {es}, you configure a PKI realm, enable client authentication on the desired network layers (transport or http), and map the Distinguished Name -(DN) from the Subject field in the user certificate to roles, using the +(DN) from the Subject field in the user certificate to roles by using the <> or the role-mapping file. You can also use a combination of PKI and username/password authentication. For From f70ce0aeb75714aac152549fedb515ed5186aeb7 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:09:33 +0300 Subject: [PATCH 14/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 852dac9a55045..1aa2c17502f70 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -95,7 +95,7 @@ restart for last. + -- -When clients connect directly to {es}, and are not proxy-authenticated by +When clients connect directly to {es} and are not proxy-authenticated by {kib}, the PKI realm relies on the TLS settings of the node's network interface. The realm can be configured to be more restrictive than the underlying network connection - that is, it is possible to configure the node From de49e1e8c0b6ee20f673b23a3d16daccca5db0a6 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:09:45 +0300 Subject: [PATCH 15/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 1aa2c17502f70..d5d8d7960400a 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -98,7 +98,7 @@ restart for last. When clients connect directly to {es} and are not proxy-authenticated by {kib}, the PKI realm relies on the TLS settings of the node's network interface. The realm can be configured to be more restrictive than the -underlying network connection - that is, it is possible to configure the node +underlying network connection. That is to say, it is possible to configure the node such that some connections are accepted by the network interface but then fail to be authenticated by the PKI realm. However, the reverse is not possible. The PKI realm cannot authenticate a connection that has been refused by the network From f9397be389b3edc3cbc320de2734e8751239fb82 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:09:54 +0300 Subject: [PATCH 16/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index d5d8d7960400a..877b02eb8fae5 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -159,7 +159,7 @@ simultaneously. + -- You map roles for PKI users through the <> or by using a file stored on each node. Configurations of both +mapping APIs>> or by using a file stored on each node. Both configuration options are merged together. When a user authenticates against a PKI realm, the privileges for that user are the union of all privileges defined by the roles to which the user is mapped. From 4913e52a9574d56b7d1ce02fbe70bd2311d8175d Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:10:04 +0300 Subject: [PATCH 17/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 877b02eb8fae5..1e6b30fd71293 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -151,7 +151,7 @@ xpack.security.authc.realms.pki.pki1.truststore.secure_password The `certificate_authorities` option can be used as an alternative to the `truststore.path` setting, when the certificate files are PEM formatted -(accepts a list). The two options are exclusive, they cannot be both used +. The setting accepts a list. The two options are exclusive, they cannot be both used simultaneously. -- From 9c0ab8b197e5f09a3f82dd411823a6475d54dd8f Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:10:14 +0300 Subject: [PATCH 18/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 1e6b30fd71293..bd7ddc2b72dd4 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -184,7 +184,7 @@ PUT /_security/role_mapping/users <1> The distinguished name (DN) of a PKI user. Or, alternatively, configured inside a role-mapping file. The file's path -defaults to `ES_PATH_CONF/role_mapping.yml` but a different path, also inside +defaults to `ES_PATH_CONF/role_mapping.yml`. You can specify a different path--also inside ES_PATH_CONF, may be specified by the realm setting `files.role_mapping` (e.g. `xpack.security.authc.realms.pki.pki1.files.role_mapping`): From c6b98fdc22fdc3a22512d03c3fda2f5db0972a0b Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:10:27 +0300 Subject: [PATCH 19/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index bd7ddc2b72dd4..1582bfd84eb28 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -185,7 +185,7 @@ PUT /_security/role_mapping/users Or, alternatively, configured inside a role-mapping file. The file's path defaults to `ES_PATH_CONF/role_mapping.yml`. You can specify a different path--also inside -ES_PATH_CONF, may be specified by the realm setting `files.role_mapping` (e.g. +ES_PATH_CONF--by using the `files.role_mapping` realm setting (e.g. `xpack.security.authc.realms.pki.pki1.files.role_mapping`): [source, yaml] From c75b473cd6b1d4d5659509b53da562492724ed5c Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:10:37 +0300 Subject: [PATCH 20/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 1582bfd84eb28..c9eaff7c8837a 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -222,7 +222,7 @@ alternative to role mapping. [[pki-realm-for-proxied-clients]] ==== PKI authentication for clients connecting to {kib} -Clients must normally connect directly to {es}, because the {es} PKI realm +Clients must normally connect directly to {es} because the {es} PKI realm relies on the node's network interface to do the SSL/TLS authentication and to also internally forward the client's certificate chain for the realm to be able to optionally validate it. If SSL/TLS authenticatication is to be performed From 565dd1587b2f921368e7c7030aa1d13da99199fc Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:10:50 +0300 Subject: [PATCH 21/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index c9eaff7c8837a..0ab88540dd0a8 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -226,7 +226,7 @@ Clients must normally connect directly to {es} because the {es} PKI realm relies on the node's network interface to do the SSL/TLS authentication and to also internally forward the client's certificate chain for the realm to be able to optionally validate it. If SSL/TLS authenticatication is to be performed -by {kib}, then the PKI realm must be configured to permit delegating it. +by {kib}, the PKI realm must be configured to permit delegation. Specifically, when clients presenting X.509 certificates connect to {kib}, {kib} will perform the SSL/TLS authentication and will forward the client's From 94edf48fe83bc96a314416ad69853192da48598a Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:11:04 +0300 Subject: [PATCH 22/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 0ab88540dd0a8..3fa96eef83854 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -255,7 +255,7 @@ authenticated by delegation to {kib} indistinctly follow the same {stack-ov}/realm-chains.html#authorization_realms[authorization realms configurations]. If using the <>, it is possible to distinguish between users authenticated by delegation from -users authenticated directly, because the former ones have the following two +users that are authenticated directly. The former have the extra fields `pki_delegated_by_user` and `pki_delegated_by_realm` in the user's metadata. In the common setup, where authentication is delegated to {kib}, the values of these fields are `kibana` and `reserved`, respectively. For example, From c3808daf87f747fd451858c6eab39a62c200c42a Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:11:14 +0300 Subject: [PATCH 23/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 3fa96eef83854..c5485b2ae1d89 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -254,7 +254,7 @@ authenticated by delegation to {kib} indistinctly follow the same {stack-ov}/mapping-roles.html[role mapping rules] or {stack-ov}/realm-chains.html#authorization_realms[authorization realms configurations]. If using the <>, -it is possible to distinguish between users authenticated by delegation from +you can distinguish between users that are authenticated by delegation and users that are authenticated directly. The former have the extra fields `pki_delegated_by_user` and `pki_delegated_by_realm` in the user's metadata. In the common setup, where authentication is delegated to {kib}, the From b6472982cbf87c4309f49f4ef802a811f1e6dc7f Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:11:24 +0300 Subject: [PATCH 24/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index c5485b2ae1d89..7bbfa9709b89e 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -253,7 +253,7 @@ connecting directly to {es}. Directly authenticated users and users PKI authenticated by delegation to {kib} indistinctly follow the same {stack-ov}/mapping-roles.html[role mapping rules] or {stack-ov}/realm-chains.html#authorization_realms[authorization realms -configurations]. If using the <>, +configurations]. If you use the <>, you can distinguish between users that are authenticated by delegation and users that are authenticated directly. The former have the extra fields `pki_delegated_by_user` and `pki_delegated_by_realm` in the user's From 3dc8b1ff21dd3698f9d94cf2b39c3951ebf644e2 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:11:35 +0300 Subject: [PATCH 25/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 7bbfa9709b89e..38bee93fc1056 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -249,7 +249,7 @@ NOTE: PKI authentication delegation requires that NOTE: {kib} also needs to be configured to allow PKI certificate authentication. A PKI realm with `delegation.enabled` still works unchanged for clients -connecting directly to {es}. Directly authenticated users and users PKI +connecting directly to {es}. Directly authenticated users and users that are PKI authenticated by delegation to {kib} indistinctly follow the same {stack-ov}/mapping-roles.html[role mapping rules] or {stack-ov}/realm-chains.html#authorization_realms[authorization realms From 20c2db894fc8714ece114b6ecb79d06496f582dd Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:11:43 +0300 Subject: [PATCH 26/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 38bee93fc1056..0fcac737ddace 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -244,7 +244,7 @@ This realm is now allowed to validate delegated PKI authentication (after restarting {es}). NOTE: PKI authentication delegation requires that -`xpack.security.authc.token.enabled` be `true`. +the `xpack.security.authc.token.enabled` setting is `true`. NOTE: {kib} also needs to be configured to allow PKI certificate authentication. From 2ada54d12aefbffd00c66844da0c5efa6b3cfc94 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:11:51 +0300 Subject: [PATCH 27/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 0fcac737ddace..50a27f38923c2 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -229,7 +229,7 @@ to optionally validate it. If SSL/TLS authenticatication is to be performed by {kib}, the PKI realm must be configured to permit delegation. Specifically, when clients presenting X.509 certificates connect to {kib}, -{kib} will perform the SSL/TLS authentication and will forward the client's +{kib} performs the SSL/TLS authentication. {kib} then forwards the client's certificate chain, by calling an {es} API, to have them further validated by the PKI realms that have been configured for delegation. From dc14a70643f1d50e3adcfc3052b7555230235a7f Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:12:04 +0300 Subject: [PATCH 28/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 50a27f38923c2..340d9f29ddaaa 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -235,7 +235,7 @@ the PKI realms that have been configured for delegation. To permit authentication delegation for a specific {es} PKI realm, start by configuring the realm for the usual case, as detailed in the -<> directly to {es}>> section, but make sure that you have explicitly configured a `truststore` (or, equivalently `certificate_authorities`) even though it is the same trust configuration that you have configured on the network layer. From 3df44f5f63bd3fe92a4a2de1d22d7327cb7e5d9d Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:12:15 +0300 Subject: [PATCH 29/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Lisa Cawley --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 340d9f29ddaaa..efe6d2c22a1b7 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -236,7 +236,7 @@ the PKI realms that have been configured for delegation. To permit authentication delegation for a specific {es} PKI realm, start by configuring the realm for the usual case, as detailed in the <> -directly to {es}>> section, but make sure that you have explicitly configured +section. However, you must make sure that you have explicitly configured a `truststore` (or, equivalently `certificate_authorities`) even though it is the same trust configuration that you have configured on the network layer. Afterwards, simply toggle the `delegation.enabled` realm setting to `true`. From 50a70e5f050c5e4755439b0048e75b2a7329574a Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 8 Aug 2019 21:13:54 +0300 Subject: [PATCH 30/45] Indistinctly -> Both --- .../en/security/authentication/configuring-pki-realm.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index efe6d2c22a1b7..5562c1e7c93f6 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -249,8 +249,8 @@ the `xpack.security.authc.token.enabled` setting is `true`. NOTE: {kib} also needs to be configured to allow PKI certificate authentication. A PKI realm with `delegation.enabled` still works unchanged for clients -connecting directly to {es}. Directly authenticated users and users that are PKI -authenticated by delegation to {kib} indistinctly follow the same +connecting directly to {es}. Directly authenticated users, and users that are PKI +authenticated by delegation to {kib} both follow the same {stack-ov}/mapping-roles.html[role mapping rules] or {stack-ov}/realm-chains.html#authorization_realms[authorization realms configurations]. If you use the <>, From e422227e96794399608e095a5f4d01517069e4c4 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Tue, 20 Aug 2019 10:33:49 +0300 Subject: [PATCH 31/45] Yogesh's review --- .../settings/security-settings.asciidoc | 8 ++-- .../configuring-pki-realm.asciidoc | 38 ++++++++++--------- 2 files changed, 25 insertions(+), 21 deletions(-) diff --git a/docs/reference/settings/security-settings.asciidoc b/docs/reference/settings/security-settings.asciidoc index 133aecd33a49d..bcde849402086 100644 --- a/docs/reference/settings/security-settings.asciidoc +++ b/docs/reference/settings/security-settings.asciidoc @@ -861,10 +861,10 @@ must connect directly to {es}. That is, they must not pass through proxies which terminate the TLS connection. In order to allow for a *trusted* and *smart* proxy, such as Kibana, to sit before {es} and terminate TLS connections, but still allow clients to be authenticated on {es} by this realm, -you need to toggle this to `true`. Defaults to `false`. This setting requires -that the `truststore.path` or `certificate_authorities` settings be defined as -well. For more details, see <>. +you need to toggle this to `true`. Defaults to `false`. If delegation is +enabled, then either `truststore.path` or `certificate_authorities` setting +must be defined. For more details, see <>. [[ref-saml-settings]] [float] diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 5562c1e7c93f6..931af26685d8c 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -6,11 +6,13 @@ You can configure {es} to use Public Key Infrastructure (PKI) certificates to authenticate users. This requires clients connecting directly to {es} to present X.509 certificates. The certificates must first be accepted for authentication on the SSL/TLS layer on {es}. Only then they are optionally -further validated by a PKI realm. Users might also connect to {kib} and -present their certificate, but this requires a little -<>. On {es}, this -configuration enables {kib} to act as a proxy for SSL/TLS authentication and -to submit the client certificates to {es} for further validation by a PKI realm. +further validated by a PKI realm. + +Users might also connect to {kib} and present their certificate, but this +requires a little <>. On +{es}, this configuration enables {kib} to act as a proxy for SSL/TLS +authentication and to submit the client certificates to {es} for further +validation by a PKI realm. For more general information, see {stack-ov}/pki-realm.html[PKI user authentication]. @@ -31,9 +33,10 @@ authenticating HTTP traffic using username and password credentials. You can also set `xpack.security.transport.ssl.client_authentication` to `optional` to allow clients without certificates to authenticate with other credentials. -IMPORTANT: You must enable SSL/TLS and enable client authentication, if you -only allow PKI authentication for clients connecting directly to {es}, but not -through {kib}. +IMPORTANT: You must enable SSL/TLS to use PKI. If a PKI realm does **not** +support delegation, i.e. only allows for clients connecting directly to {es} +and not through {kib}, then SSL/TLS client authentication must be enabled as +well. . Add a realm configuration for a `pki` realm to `elasticsearch.yml` under the `xpack.security.authc.realms.pki` namespace. @@ -95,14 +98,13 @@ restart for last. + -- -When clients connect directly to {es} and are not proxy-authenticated by -{kib}, the PKI realm relies on the TLS settings of the node's network -interface. The realm can be configured to be more restrictive than the -underlying network connection. That is to say, it is possible to configure the node -such that some connections are accepted by the network interface but then fail -to be authenticated by the PKI realm. However, the reverse is not possible. The -PKI realm cannot authenticate a connection that has been refused by the network -interface. +When clients connect directly to {es} and are not proxy-authenticated, the PKI +realm relies on the TLS settings of the node's network interface. The realm can +be configured to be more restrictive than the underlying network connection. +That is to say, it is possible to configure the node such that some connections +are accepted by the network interface but then fail to be authenticated by the +PKI realm. However, the reverse is not possible. The PKI realm cannot +authenticate a connection that has been refused by the network interface. In particular this means: @@ -253,7 +255,9 @@ connecting directly to {es}. Directly authenticated users, and users that are PK authenticated by delegation to {kib} both follow the same {stack-ov}/mapping-roles.html[role mapping rules] or {stack-ov}/realm-chains.html#authorization_realms[authorization realms -configurations]. If you use the <>, +configurations]. + +However, if you use the <>, you can distinguish between users that are authenticated by delegation and users that are authenticated directly. The former have the extra fields `pki_delegated_by_user` and `pki_delegated_by_realm` in the user's From c108f12ad2924f01eaeba2efa2080cf58b5d505d Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 10:58:07 +0300 Subject: [PATCH 32/45] Update x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc Co-Authored-By: Tim Vernum --- .../en/rest-api/security/delegate-pki-authentication.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc index edfa30dd67b77..441ab6c65434d 100644 --- a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc +++ b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc @@ -13,7 +13,7 @@ token. `POST /_security/delegate_pki` -[[security-api-dellegate-pki-authentication-prereqs]] +[[security-api-delegate-pki-authentication-prereqs]] ==== {api-prereq-title} * To call this API, the (proxy) user must have the `delegate_pki` or the `all` From 9f214206161a17c402eccd2834d7b6a4228f569b Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 10:58:22 +0300 Subject: [PATCH 33/45] Update x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc Co-Authored-By: Tim Vernum --- .../en/rest-api/security/delegate-pki-authentication.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc index 441ab6c65434d..92d82f1c273e9 100644 --- a/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc +++ b/x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc @@ -48,7 +48,7 @@ this API translates that authentication into an {es} access token. `x509_certificate_chain`:: (Required, list of strings) The _X509Certificate_ chain, which is represented as an ordered string array. Each string in the array is a base64-encoded -(Section 4 of RFC4648 - not base64url-encoded) DER PKIX certificate value. +(Section 4 of RFC4648 - not base64url-encoded) of the certificate's DER encoding. + The first element is the target certificate contains the subject distinguished name that is requesting access. This may be followed by additional certificates; From 03046d3c96218f99156fdf1ad5d188e354796b1c Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:01:38 +0300 Subject: [PATCH 34/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 931af26685d8c..3ed086b36d639 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -8,7 +8,7 @@ present X.509 certificates. The certificates must first be accepted for authentication on the SSL/TLS layer on {es}. Only then they are optionally further validated by a PKI realm. -Users might also connect to {kib} and present their certificate, but this +Users may also use PKI certificates to authenticate to {kib}, however this requires a little <>. On {es}, this configuration enables {kib} to act as a proxy for SSL/TLS authentication and to submit the client certificates to {es} for further From 87760b1b432a7c3a9aedeb601c6d1ed75b3f19e4 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:05:40 +0300 Subject: [PATCH 35/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 3ed086b36d639..0e7e4d6c0a2c4 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -9,7 +9,7 @@ authentication on the SSL/TLS layer on {es}. Only then they are optionally further validated by a PKI realm. Users may also use PKI certificates to authenticate to {kib}, however this -requires a little <>. On +requires some <>. On {es}, this configuration enables {kib} to act as a proxy for SSL/TLS authentication and to submit the client certificates to {es} for further validation by a PKI realm. From 07ba8276558a8d4429c7717cb8c10d8f2de352de Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:12:36 +0300 Subject: [PATCH 36/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 0e7e4d6c0a2c4..ecd9243381447 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -61,7 +61,7 @@ xpack: With this configuration, any certificate trusted by the {es} SSL/TLS layer is accepted for authentication. The username is the common name (CN) extracted from the DN in the Subject field of the end-entity certificate. This -configuration does not permit clients authenticating to {kib}. +configuration does not permit PKI authentication to {kib}. IMPORTANT: When you configure realms in `elasticsearch.yml`, only the realms you specify are used for authentication. If you also want to use the From 6e79cc591d95693a5a04c5b42333a2cdf5ea0d18 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:12:53 +0300 Subject: [PATCH 37/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index ecd9243381447..d07e1e5422949 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -101,7 +101,7 @@ restart for last. When clients connect directly to {es} and are not proxy-authenticated, the PKI realm relies on the TLS settings of the node's network interface. The realm can be configured to be more restrictive than the underlying network connection. -That is to say, it is possible to configure the node such that some connections +That is, it is possible to configure the node such that some connections are accepted by the network interface but then fail to be authenticated by the PKI realm. However, the reverse is not possible. The PKI realm cannot authenticate a connection that has been refused by the network interface. From b88e2c937d679aab5902420bc77523a4275c0dbc Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:13:22 +0300 Subject: [PATCH 38/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index d07e1e5422949..98ef8bdb9c806 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -138,7 +138,7 @@ xpack: pki: pki1: truststore: - path: "ES_PATH_CONF/pki1_truststore.jks" + path: "pki1_truststore.jks" ------------------------------------------------------------ If the truststore is password protected, the password should be configured by From 7a52c2469a617a9993708040f10afa671b302122 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:14:42 +0300 Subject: [PATCH 39/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 98ef8bdb9c806..e16119b17fa7e 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -186,7 +186,7 @@ PUT /_security/role_mapping/users <1> The distinguished name (DN) of a PKI user. Or, alternatively, configured inside a role-mapping file. The file's path -defaults to `ES_PATH_CONF/role_mapping.yml`. You can specify a different path--also inside +defaults to `ES_PATH_CONF/role_mapping.yml`. You can specify a different path (which must be within ES_PATH_CONF--by using the `files.role_mapping` realm setting (e.g. `xpack.security.authc.realms.pki.pki1.files.role_mapping`): From 33baf1786cafb7e4f9325eb7af9ea9e39a5db41d Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:15:04 +0300 Subject: [PATCH 40/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../en/security/authentication/configuring-pki-realm.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index e16119b17fa7e..d487d7476a71d 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -187,7 +187,7 @@ PUT /_security/role_mapping/users Or, alternatively, configured inside a role-mapping file. The file's path defaults to `ES_PATH_CONF/role_mapping.yml`. You can specify a different path (which must be within -ES_PATH_CONF--by using the `files.role_mapping` realm setting (e.g. +ES_PATH_CONF) by using the `files.role_mapping` realm setting (e.g. `xpack.security.authc.realms.pki.pki1.files.role_mapping`): [source, yaml] From ade36bdf73d679899f4dfed020a3c09d6c59598c Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 11:17:25 +0300 Subject: [PATCH 41/45] Update x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc Co-Authored-By: Tim Vernum --- .../security/authentication/configuring-pki-realm.asciidoc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index d487d7476a71d..584ad2f1cc102 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -238,7 +238,10 @@ the PKI realms that have been configured for delegation. To permit authentication delegation for a specific {es} PKI realm, start by configuring the realm for the usual case, as detailed in the <> -section. However, you must make sure that you have explicitly configured +section. Note that you must explicitly configure a `truststore` +(or, equivalently `certificate_authorities`) when configuring +a PKI realm for delegation, as delegated PKI will not automatically +make use of the network layer's trust settings. a `truststore` (or, equivalently `certificate_authorities`) even though it is the same trust configuration that you have configured on the network layer. Afterwards, simply toggle the `delegation.enabled` realm setting to `true`. From 229454403e4ca12b18d3ceb8ac5c6e483e038abe Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 12:17:14 +0300 Subject: [PATCH 42/45] Tim's review --- .../configuring-pki-realm.asciidoc | 25 ++++++++----------- .../authorization/mapping-roles.asciidoc | 3 +++ 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 584ad2f1cc102..d8b2fc4f769a7 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -33,10 +33,8 @@ authenticating HTTP traffic using username and password credentials. You can also set `xpack.security.transport.ssl.client_authentication` to `optional` to allow clients without certificates to authenticate with other credentials. -IMPORTANT: You must enable SSL/TLS to use PKI. If a PKI realm does **not** -support delegation, i.e. only allows for clients connecting directly to {es} -and not through {kib}, then SSL/TLS client authentication must be enabled as -well. +IMPORTANT: You must enable SSL/TLS with client authentication to use PKI when +clients connect directly to {es}. . Add a realm configuration for a `pki` realm to `elasticsearch.yml` under the `xpack.security.authc.realms.pki` namespace. @@ -224,10 +222,10 @@ alternative to role mapping. [[pki-realm-for-proxied-clients]] ==== PKI authentication for clients connecting to {kib} -Clients must normally connect directly to {es} because the {es} PKI realm -relies on the node's network interface to do the SSL/TLS authentication and to -also internally forward the client's certificate chain for the realm to be able -to optionally validate it. If SSL/TLS authenticatication is to be performed +By default, the PKI realm relies on the node's network interface to perform the +SSL/TLS handshake and extract the client certificate. This behaviour requires +that that clients connect directly to {es} so that their SSL connection is +terminated by the {es} node. If SSL/TLS authenticatication is to be performed by {kib}, the PKI realm must be configured to permit delegation. Specifically, when clients presenting X.509 certificates connect to {kib}, @@ -248,8 +246,9 @@ Afterwards, simply toggle the `delegation.enabled` realm setting to `true`. This realm is now allowed to validate delegated PKI authentication (after restarting {es}). -NOTE: PKI authentication delegation requires that -the `xpack.security.authc.token.enabled` setting is `true`. +NOTE: PKI authentication delegation requires that the +`xpack.security.authc.token.enabled` setting be `true` and that SSL/TLS be +configured (without SSL/TLS client authentication). NOTE: {kib} also needs to be configured to allow PKI certificate authentication. @@ -281,10 +280,8 @@ PUT /_security/role_mapping/direct_pki_only "field": {"realm.name": "pki1"} }, { - "except": { - "field": { - "metadata.pki_delegated_by_user": null <1> - } + "field": { + "metadata.pki_delegated_by_user": null <1> } } ] diff --git a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc index 93918a7753d5c..797b817ecdb65 100644 --- a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc +++ b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc @@ -28,6 +28,9 @@ you are able to map users to both API-managed roles and file-managed roles NOTE: The PKI, LDAP, Kerberos and SAML realms support using <> as an alternative to role mapping. +NOTE: When anonymous access is enabled the roles of the anonymous user are +mapped to all the other users as well. + NOTE: Users with no roles assigned will be unauthorized for any action. [[mapping-roles-api]] From a4f8bd55860cf56219238e53187f9caf22357016 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Thu, 22 Aug 2019 12:20:14 +0300 Subject: [PATCH 43/45] Ref --- x-pack/docs/en/security/authorization/mapping-roles.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc index 797b817ecdb65..c4950d18f55c4 100644 --- a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc +++ b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc @@ -28,8 +28,8 @@ you are able to map users to both API-managed roles and file-managed roles NOTE: The PKI, LDAP, Kerberos and SAML realms support using <> as an alternative to role mapping. -NOTE: When anonymous access is enabled the roles of the anonymous user are -mapped to all the other users as well. +NOTE: When {ref}/anonymous-access.html[anonymous access] is enabled the roles +of the anonymous user are mapped to all the other users as well. NOTE: Users with no roles assigned will be unauthorized for any action. From 3ec4656b4649092a29b07d55ce50a5f04a5d710d Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Fri, 23 Aug 2019 11:46:24 +0300 Subject: [PATCH 44/45] Fix --- .../authentication/configuring-pki-realm.asciidoc | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index d8b2fc4f769a7..a3fc1a6c0b0a1 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -236,15 +236,11 @@ the PKI realms that have been configured for delegation. To permit authentication delegation for a specific {es} PKI realm, start by configuring the realm for the usual case, as detailed in the <> -section. Note that you must explicitly configure a `truststore` -(or, equivalently `certificate_authorities`) when configuring -a PKI realm for delegation, as delegated PKI will not automatically -make use of the network layer's trust settings. -a `truststore` (or, equivalently `certificate_authorities`) even though it is -the same trust configuration that you have configured on the network layer. -Afterwards, simply toggle the `delegation.enabled` realm setting to `true`. -This realm is now allowed to validate delegated PKI authentication (after -restarting {es}). +section. Note that you must explicitly configure a `truststore` (or, +equivalently `certificate_authorities`) even though it is the same trust +configuration that you have configured on the network layer. Afterwards, +simply toggle the `delegation.enabled` realm setting to `true`. This realm is +now allowed to validate delegated PKI authentication (after restarting {es}). NOTE: PKI authentication delegation requires that the `xpack.security.authc.token.enabled` setting be `true` and that SSL/TLS be From 8ed1ef9a182bee76d944381e423478ff87545120 Mon Sep 17 00:00:00 2001 From: Albert Zaharovits Date: Fri, 23 Aug 2019 12:32:04 +0300 Subject: [PATCH 45/45] ClearRealmCacheRequestBuilder --- .../security/authc/pki/PkiAuthDelegationIntegTests.java | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/pki/PkiAuthDelegationIntegTests.java b/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/pki/PkiAuthDelegationIntegTests.java index 28beeed8cbcfa..fd84e71b91e0a 100644 --- a/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/pki/PkiAuthDelegationIntegTests.java +++ b/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/pki/PkiAuthDelegationIntegTests.java @@ -26,7 +26,9 @@ import org.elasticsearch.test.SecurityIntegTestCase; import org.elasticsearch.test.SecuritySettingsSourceField; import org.elasticsearch.xpack.core.XPackSettings; +import org.elasticsearch.xpack.core.security.action.realm.ClearRealmCacheRequestBuilder; import org.elasticsearch.xpack.core.security.authc.support.Hasher; +import org.junit.Before; import org.elasticsearch.test.SecuritySettingsSource; import java.io.InputStream; @@ -120,6 +122,11 @@ protected boolean addMockHttpTransport() { return false; // enable http } + @Before + void clearRealmCache() { + new ClearRealmCacheRequestBuilder(client()).get(); + } + public void testDelegateThenAuthenticate() throws Exception { final X509Certificate clientCertificate = readCertForPkiDelegation("testClient.crt"); final X509Certificate intermediateCA = readCertForPkiDelegation("testIntermediateCA.crt");