diff --git a/x-pack/docs/en/rest-api/security/authenticate.asciidoc b/x-pack/docs/en/rest-api/security/authenticate.asciidoc index f5f6e2d33a6cf..fc12e1dfb0f0e 100644 --- a/x-pack/docs/en/rest-api/security/authenticate.asciidoc +++ b/x-pack/docs/en/rest-api/security/authenticate.asciidoc @@ -31,15 +31,14 @@ If the user cannot be authenticated, this API returns a 401 status code. To authenticate a user, submit a GET request to the `/_security/_authenticate` endpoint: -[source,js] +[source,console] -------------------------------------------------- GET /_security/_authenticate -------------------------------------------------- -// CONSOLE The following example output provides information about the "rdeniro" user: -[source,js] +[source,console-result] -------------------------------------------------- { "username": "rdeniro", diff --git a/x-pack/docs/en/rest-api/security/change-password.asciidoc b/x-pack/docs/en/rest-api/security/change-password.asciidoc index 07947088048b0..ed696d668bc99 100644 --- a/x-pack/docs/en/rest-api/security/change-password.asciidoc +++ b/x-pack/docs/en/rest-api/security/change-password.asciidoc @@ -51,20 +51,18 @@ For more information about the native realm, see The following example updates the password for the `jacknich` user: -[source,js] +[source,console] -------------------------------------------------- POST /_security/user/jacknich/_password { "password" : "s3cr3t" } -------------------------------------------------- -// CONSOLE // TEST[setup:jacknich_user] A successful call returns an empty JSON structure. -[source,js] +[source,console-result] -------------------------------------------------- {} -------------------------------------------------- -// TESTRESPONSE diff --git a/x-pack/docs/en/rest-api/security/clear-cache.asciidoc b/x-pack/docs/en/rest-api/security/clear-cache.asciidoc index 2b2ed8f91686c..a214163ed1799 100644 --- a/x-pack/docs/en/rest-api/security/clear-cache.asciidoc +++ b/x-pack/docs/en/rest-api/security/clear-cache.asciidoc @@ -44,25 +44,22 @@ To evict roles from the role cache, see the For example, to evict all users cached by the `file` realm: -[source,js] +[source,console] -------------------------------------------------- POST /_security/realm/default_file/_clear_cache -------------------------------------------------- -// CONSOLE To evict selected users, specify the `usernames` parameter: -[source,js] +[source,console] -------------------------------------------------- POST /_security/realm/default_file/_clear_cache?usernames=rdeniro,alpacino -------------------------------------------------- -// CONSOLE To clear the caches for multiple realms, specify the realms as a comma-delimited list: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/realm/default_file,ldap1/_clear_cache ------------------------------------------------------------ -// CONSOLE diff --git a/x-pack/docs/en/rest-api/security/clear-roles-cache.asciidoc b/x-pack/docs/en/rest-api/security/clear-roles-cache.asciidoc index eb8a721c835bb..8fc8f0b883902 100644 --- a/x-pack/docs/en/rest-api/security/clear-roles-cache.asciidoc +++ b/x-pack/docs/en/rest-api/security/clear-roles-cache.asciidoc @@ -36,8 +36,7 @@ For more information about the native realm, see The clear roles cache API evicts roles from the native role cache. For example, to clear the cache for `my_admin_role`: -[source,js] +[source,console] -------------------------------------------------- POST /_security/role/my_admin_role/_clear_cache -------------------------------------------------- -// CONSOLE diff --git a/x-pack/docs/en/rest-api/security/create-api-keys.asciidoc b/x-pack/docs/en/rest-api/security/create-api-keys.asciidoc index f0199134ce666..65c2a9bf9e9d4 100644 --- a/x-pack/docs/en/rest-api/security/create-api-keys.asciidoc +++ b/x-pack/docs/en/rest-api/security/create-api-keys.asciidoc @@ -65,7 +65,7 @@ expire. The following example creates an API key: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/api_key { @@ -93,7 +93,6 @@ POST /_security/api_key } } ------------------------------------------------------------ -// CONSOLE <1> optional expiration for the API key being generated. If expiration is not provided then the API keys do not expire. <2> optional role descriptors for this API key, if not provided then permissions @@ -102,7 +101,7 @@ POST /_security/api_key A successful call returns a JSON structure that provides API key information. -[source,js] +[source,console-result] -------------------------------------------------- { "id":"VuaCfGcBCdbkQm-e5aOx", <1> diff --git a/x-pack/docs/en/rest-api/security/create-role-mappings.asciidoc b/x-pack/docs/en/rest-api/security/create-role-mappings.asciidoc index f2a43427d9e9b..de727a70b71eb 100644 --- a/x-pack/docs/en/rest-api/security/create-role-mappings.asciidoc +++ b/x-pack/docs/en/rest-api/security/create-role-mappings.asciidoc @@ -105,7 +105,7 @@ The Examples section below demonstrates the use of templated role names. The following example assigns the "user" role to all users: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping1 { @@ -119,7 +119,6 @@ POST /_security/role_mapping/mapping1 } } ------------------------------------------------------------ -// CONSOLE <1> Mappings that have `enabled` set to `false` are ignored when role mapping is performed. <2> Metadata is optional. @@ -127,7 +126,7 @@ POST /_security/role_mapping/mapping1 A successful call returns a JSON structure that shows whether the mapping has been created or updated. -[source,js] +[source,console-result] -------------------------------------------------- { "role_mapping" : { @@ -135,12 +134,11 @@ been created or updated. } } -------------------------------------------------- -// 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] +[source,console] -------------------------------------------------- POST /_security/role_mapping/mapping2 { @@ -151,10 +149,9 @@ POST /_security/role_mapping/mapping2 } } -------------------------------------------------- -// CONSOLE The following example matches users who authenticated against a specific realm: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping3 { @@ -165,12 +162,11 @@ POST /_security/role_mapping/mapping3 } } ------------------------------------------------------------ -// 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] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping4 { @@ -192,7 +188,6 @@ POST /_security/role_mapping/mapping4 } } ------------------------------------------------------------ -// 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 @@ -213,7 +208,7 @@ 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] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping5 { @@ -229,7 +224,6 @@ POST /_security/role_mapping/mapping5 "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 @@ -237,7 +231,7 @@ POST /_security/role_mapping/mapping5 The following example matches users within a specific LDAP sub-tree: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping6 { @@ -248,12 +242,11 @@ POST /_security/role_mapping/mapping6 } } ------------------------------------------------------------ -// CONSOLE The following example matches users within a particular LDAP sub-tree in a specific realm: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping7 { @@ -267,7 +260,6 @@ POST /_security/role_mapping/mapping7 } } ------------------------------------------------------------ -// 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: @@ -278,7 +270,7 @@ following mapping matches any user where *all* of these conditions are met: - the user does not have a `terminated_date` -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping8 { @@ -316,7 +308,6 @@ POST /_security/role_mapping/mapping8 } } ------------------------------------------------------------ -// 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 @@ -329,7 +320,7 @@ 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] +[source,console] ------------------------------------------------------------ POST /_security/role_mapping/mapping9 { @@ -341,7 +332,6 @@ POST /_security/role_mapping/mapping9 "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. diff --git a/x-pack/docs/en/rest-api/security/create-roles.asciidoc b/x-pack/docs/en/rest-api/security/create-roles.asciidoc index 4976675c698c9..85f549d635f74 100644 --- a/x-pack/docs/en/rest-api/security/create-roles.asciidoc +++ b/x-pack/docs/en/rest-api/security/create-roles.asciidoc @@ -82,7 +82,7 @@ For more information, see {stack-ov}/defining-roles.html[Defining roles]. The following example adds a role called `my_admin_role`: -[source,js] +[source,console] -------------------------------------------------- POST /_security/role/my_admin_role { @@ -110,12 +110,11 @@ POST /_security/role/my_admin_role } } -------------------------------------------------- -// CONSOLE A successful call returns a JSON structure that shows whether the role has been created or updated. -[source,js] +[source,console-result] -------------------------------------------------- { "role": { @@ -123,5 +122,4 @@ created or updated. } } -------------------------------------------------- -// TESTRESPONSE <1> When an existing role is updated, `created` is set to false. diff --git a/x-pack/docs/en/rest-api/security/create-users.asciidoc b/x-pack/docs/en/rest-api/security/create-users.asciidoc index 0135f230912b9..e331c8724770d 100644 --- a/x-pack/docs/en/rest-api/security/create-users.asciidoc +++ b/x-pack/docs/en/rest-api/security/create-users.asciidoc @@ -104,7 +104,7 @@ access permissions. To create a user without any roles, specify an empty list: The following example creates a user `jacknich`: -[source,js] +[source,console] -------------------------------------------------- POST /_security/user/jacknich { @@ -117,18 +117,16 @@ POST /_security/user/jacknich } } -------------------------------------------------- -// CONSOLE A successful call returns a JSON structure that shows whether the user has been created or updated. -[source,js] +[source,console-result] -------------------------------------------------- { "created": true <1> } -------------------------------------------------- -// TESTRESPONSE <1> When an existing user is updated, `created` is set to false. After you add a user, requests from that user can be authenticated. For example: 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 b8d20b23953b8..d1bec9ae8dcfd 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 @@ -73,19 +73,18 @@ client's certificate. The following is an example request: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/delegate_pki { "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> A one element certificate chain. Which returns the following response: -[source,js] +[source,console-result] -------------------------------------------------- { "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==", diff --git a/x-pack/docs/en/rest-api/security/delete-app-privileges.asciidoc b/x-pack/docs/en/rest-api/security/delete-app-privileges.asciidoc index 9d54739fe9460..7f7d06289c12f 100644 --- a/x-pack/docs/en/rest-api/security/delete-app-privileges.asciidoc +++ b/x-pack/docs/en/rest-api/security/delete-app-privileges.asciidoc @@ -38,17 +38,16 @@ To use this API, you must have either: The following example deletes the `read` application privilege from the `myapp` application: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/privilege/myapp/read -------------------------------------------------- -// CONSOLE // TEST[setup:app0102_privileges] If the role is successfully deleted, the request returns `{"found": true}`. Otherwise, `found` is set to false. -[source,js] +[source,console-result] -------------------------------------------------- { "myapp": { @@ -58,5 +57,3 @@ Otherwise, `found` is set to false. } } -------------------------------------------------- -// TESTRESPONSE - diff --git a/x-pack/docs/en/rest-api/security/delete-role-mappings.asciidoc b/x-pack/docs/en/rest-api/security/delete-role-mappings.asciidoc index 8704a83c64de6..9fe2d6013cd3b 100644 --- a/x-pack/docs/en/rest-api/security/delete-role-mappings.asciidoc +++ b/x-pack/docs/en/rest-api/security/delete-role-mappings.asciidoc @@ -37,20 +37,18 @@ see {stack-ov}/mapping-roles.html[Mapping users and groups to roles]. The following example delete a role mapping: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/role_mapping/mapping1 -------------------------------------------------- -// CONSOLE // TEST[setup:role_mapping] If the mapping is successfully deleted, the request returns `{"found": true}`. Otherwise, `found` is set to false. -[source,js] +[source,console-result] -------------------------------------------------- { "found" : true } -------------------------------------------------- -// TESTRESPONSE diff --git a/x-pack/docs/en/rest-api/security/delete-roles.asciidoc b/x-pack/docs/en/rest-api/security/delete-roles.asciidoc index 2c060cb082249..dec674b657769 100644 --- a/x-pack/docs/en/rest-api/security/delete-roles.asciidoc +++ b/x-pack/docs/en/rest-api/security/delete-roles.asciidoc @@ -38,21 +38,19 @@ file-based role management. For more information about the native realm, see The following example deletes a `my_admin_role` role: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/role/my_admin_role -------------------------------------------------- -// CONSOLE // TEST[setup:admin_role] If the role is successfully deleted, the request returns `{"found": true}`. Otherwise, `found` is set to false. -[source,js] +[source,console-result] -------------------------------------------------- { "found" : true } -------------------------------------------------- -// TESTRESPONSE diff --git a/x-pack/docs/en/rest-api/security/delete-users.asciidoc b/x-pack/docs/en/rest-api/security/delete-users.asciidoc index 0db82d44f053f..db48a754f07b4 100644 --- a/x-pack/docs/en/rest-api/security/delete-users.asciidoc +++ b/x-pack/docs/en/rest-api/security/delete-users.asciidoc @@ -35,20 +35,18 @@ For more information about the native realm, see The following example deletes the user `jacknich`: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/user/jacknich -------------------------------------------------- -// CONSOLE // TEST[setup:jacknich_user] If the user is successfully deleted, the request returns `{"found": true}`. Otherwise, `found` is set to false. -[source,js] +[source,console-result] -------------------------------------------------- { "found" : true } -------------------------------------------------- -// TESTRESPONSE diff --git a/x-pack/docs/en/rest-api/security/disable-users.asciidoc b/x-pack/docs/en/rest-api/security/disable-users.asciidoc index 9b8bbe9b687c3..4f005a0673ff4 100644 --- a/x-pack/docs/en/rest-api/security/disable-users.asciidoc +++ b/x-pack/docs/en/rest-api/security/disable-users.asciidoc @@ -41,9 +41,8 @@ For more information about the native realm, see The following example disables the user `jacknich`: -[source,js] +[source,console] -------------------------------------------------- PUT /_security/user/jacknich/_disable -------------------------------------------------- -// CONSOLE // TEST[setup:jacknich_user] diff --git a/x-pack/docs/en/rest-api/security/enable-users.asciidoc b/x-pack/docs/en/rest-api/security/enable-users.asciidoc index b586c11ce74cd..34b759aa8d8da 100644 --- a/x-pack/docs/en/rest-api/security/enable-users.asciidoc +++ b/x-pack/docs/en/rest-api/security/enable-users.asciidoc @@ -40,9 +40,8 @@ For more information about the native realm, see The following example enables the user `jacknich`: -[source,js] +[source,console] -------------------------------------------------- PUT /_security/user/jacknich/_enable -------------------------------------------------- -// CONSOLE // TEST[setup:jacknich_user] diff --git a/x-pack/docs/en/rest-api/security/get-api-keys.asciidoc b/x-pack/docs/en/rest-api/security/get-api-keys.asciidoc index 1aa47ebab64cc..b655235744689 100644 --- a/x-pack/docs/en/rest-api/security/get-api-keys.asciidoc +++ b/x-pack/docs/en/rest-api/security/get-api-keys.asciidoc @@ -59,7 +59,7 @@ NOTE: At least one of "id", "name", "username" and "realm_name" must be specifie If you create an API key as follows: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/api_key { @@ -67,13 +67,11 @@ POST /_security/api_key "role_descriptors": {} } ------------------------------------------------------------ -// CONSOLE -// TEST A successful call returns a JSON structure that provides API key information. For example: -[source,js] +[source,console-result] -------------------------------------------------- { "id":"VuaCfGcBCdbkQm-e5aOx", @@ -86,80 +84,72 @@ API key information. For example: You can use the following example to retrieve the API key by ID: -[source,js] +[source,console] -------------------------------------------------- GET /_security/api_key?id=VuaCfGcBCdbkQm-e5aOx -------------------------------------------------- -// CONSOLE // TEST[s/VuaCfGcBCdbkQm-e5aOx/$body.id/] // TEST[continued] You can use the following example to retrieve the API key by name: -[source,js] +[source,console] -------------------------------------------------- GET /_security/api_key?name=my-api-key -------------------------------------------------- -// CONSOLE // TEST[continued] The following example retrieves all API keys for the `native1` realm: -[source,js] +[source,console] -------------------------------------------------- GET /_security/api_key?realm_name=native1 -------------------------------------------------- -// CONSOLE // TEST[continued] The following example retrieves all API keys for the user `myuser` in all realms: -[source,js] +[source,console] -------------------------------------------------- GET /_security/api_key?username=myuser -------------------------------------------------- -// CONSOLE // TEST[continued] The following example retrieves all API keys owned by the currently authenticated user: -[source,js] +[source,console] -------------------------------------------------- GET /_security/api_key?owner=true -------------------------------------------------- -// CONSOLE // TEST[continued] Following creates an API key -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/api_key { "name": "my-api-key-1" } ------------------------------------------------------------ -// CONSOLE The following example retrieves the API key identified by the specified `id` if it is owned by the currently authenticated user: -[source,js] +[source,console] -------------------------------------------------- GET /_security/api_key?id=VuaCfGcBCdbkQm-e5aOx&owner=true -------------------------------------------------- -// CONSOLE // TEST[s/VuaCfGcBCdbkQm-e5aOx/$body.id/] // TEST[continued] Finally, the following example retrieves all API keys for the user `myuser` in the `native1` realm immediately: -[source,js] +[source,console] -------------------------------------------------- GET /_security/api_key?username=myuser&realm_name=native1 -------------------------------------------------- -// CONSOLE // TEST[continued] A successful call returns a JSON structure that contains the information of one or more API keys that were retrieved. diff --git a/x-pack/docs/en/rest-api/security/get-app-privileges.asciidoc b/x-pack/docs/en/rest-api/security/get-app-privileges.asciidoc index 774091ba39857..bba361fd62c07 100644 --- a/x-pack/docs/en/rest-api/security/get-app-privileges.asciidoc +++ b/x-pack/docs/en/rest-api/security/get-app-privileges.asciidoc @@ -55,17 +55,16 @@ To check a user's application privileges, use the The following example retrieves information about the `read` privilege for the `app01` application: -[source,js] +[source,console] -------------------------------------------------- GET /_security/privilege/myapp/read -------------------------------------------------- -// CONSOLE // TEST[setup:app0102_privileges] A successful call returns an object keyed by application name and privilege name. If the privilege is not defined, the request responds with a 404 status. -[source,js] +[source,console-result] -------------------------------------------------- { "myapp": { @@ -83,20 +82,17 @@ name. If the privilege is not defined, the request responds with a 404 status. } } -------------------------------------------------- -// TESTRESPONSE To retrieve all privileges for an application, omit the privilege name: -[source,js] +[source,console] -------------------------------------------------- GET /_security/privilege/myapp/ -------------------------------------------------- -// CONSOLE To retrieve every privilege, omit both the application and privilege names: -[source,js] +[source,console] -------------------------------------------------- GET /_security/privilege/ -------------------------------------------------- -// CONSOLE diff --git a/x-pack/docs/en/rest-api/security/get-builtin-privileges.asciidoc b/x-pack/docs/en/rest-api/security/get-builtin-privileges.asciidoc index b9390066a0d92..7da8bdce87b3a 100644 --- a/x-pack/docs/en/rest-api/security/get-builtin-privileges.asciidoc +++ b/x-pack/docs/en/rest-api/security/get-builtin-privileges.asciidoc @@ -51,16 +51,14 @@ The response is an object with two fields: The following example retrieves the names of all builtin privileges: -[source,js] +[source,console] -------------------------------------------------- GET /_security/privilege/_builtin -------------------------------------------------- -// CONSOLE -// TEST A successful call returns an object with "cluster" and "index" fields. -[source,js] +[source,console-result] -------------------------------------------------- { "cluster" : [ @@ -115,4 +113,3 @@ A successful call returns an object with "cluster" and "index" fields. ] } -------------------------------------------------- -// TESTRESPONSE diff --git a/x-pack/docs/en/rest-api/security/get-role-mappings.asciidoc b/x-pack/docs/en/rest-api/security/get-role-mappings.asciidoc index 8d493bc0ad124..c0a77dd59b81c 100644 --- a/x-pack/docs/en/rest-api/security/get-role-mappings.asciidoc +++ b/x-pack/docs/en/rest-api/security/get-role-mappings.asciidoc @@ -55,15 +55,14 @@ response will have status code `404`. The following example retrieves information about the `mapping1` role mapping: -[source,js] +[source,console] -------------------------------------------------- GET /_security/role_mapping/mapping1 -------------------------------------------------- -// CONSOLE // TEST[setup:role_mapping] -[source,js] +[source,console-result] -------------------------------------------------- { "mapping1": { @@ -80,4 +79,3 @@ GET /_security/role_mapping/mapping1 } } -------------------------------------------------- -// TESTRESPONSE diff --git a/x-pack/docs/en/rest-api/security/get-roles.asciidoc b/x-pack/docs/en/rest-api/security/get-roles.asciidoc index 281f4e1726a43..f014166362eeb 100644 --- a/x-pack/docs/en/rest-api/security/get-roles.asciidoc +++ b/x-pack/docs/en/rest-api/security/get-roles.asciidoc @@ -51,14 +51,13 @@ If the role is not defined in the native realm, the request returns 404. The following example retrieves information about the `my_admin_role` role in the native realm: -[source,js] +[source,console] -------------------------------------------------- GET /_security/role/my_admin_role -------------------------------------------------- -// CONSOLE // TEST[setup:admin_role] -[source,js] +[source,console-result] -------------------------------------------------- { "my_admin_role": { @@ -83,14 +82,12 @@ GET /_security/role/my_admin_role } } -------------------------------------------------- -// TESTRESPONSE To retrieve all roles, omit the role name: -[source,js] +[source,console] -------------------------------------------------- GET /_security/role -------------------------------------------------- -// CONSOLE // TEST[continued] diff --git a/x-pack/docs/en/rest-api/security/get-tokens.asciidoc b/x-pack/docs/en/rest-api/security/get-tokens.asciidoc index 2bad447b8184d..7a9972bbaeb5e 100644 --- a/x-pack/docs/en/rest-api/security/get-tokens.asciidoc +++ b/x-pack/docs/en/rest-api/security/get-tokens.asciidoc @@ -81,19 +81,18 @@ other supported grant type. The following example obtains a token using the `client_credentials` grant type, which simply creates a token as the authenticated user: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oauth2/token { "grant_type" : "client_credentials" } -------------------------------------------------- -// CONSOLE The following example output contains the access token, the amount of time (in seconds) that the token expires in, and the type: -[source,js] +[source,console-result] -------------------------------------------------- { "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==", @@ -116,7 +115,7 @@ curl -H "Authorization: Bearer dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvb The following example obtains a token for the `test_admin` user using the `password` grant type: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oauth2/token { @@ -125,12 +124,11 @@ POST /_security/oauth2/token "password" : "x-pack-test-password" } -------------------------------------------------- -// CONSOLE The following example output contains the access token, the amount of time (in seconds) that the token expires in, the type, and the refresh token: -[source,js] +[source,console-result] -------------------------------------------------- { "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==", @@ -147,7 +145,7 @@ To extend the life of an existing token obtained using the `password` grant type you can call the API again with the refresh token within 24 hours of the token's creation. For example: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oauth2/token { @@ -155,14 +153,13 @@ POST /_security/oauth2/token "refresh_token": "vLBPvmAB6KvwvJZr27cS" } -------------------------------------------------- -// CONSOLE // TEST[s/vLBPvmAB6KvwvJZr27cS/$body.refresh_token/] // TEST[continued] The API will return a new token and refresh token. Each refresh token may only be used one time. -[source,js] +[source,console-result] -------------------------------------------------- { "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==", diff --git a/x-pack/docs/en/rest-api/security/get-users.asciidoc b/x-pack/docs/en/rest-api/security/get-users.asciidoc index 877035de203c4..63ae8bc140dac 100644 --- a/x-pack/docs/en/rest-api/security/get-users.asciidoc +++ b/x-pack/docs/en/rest-api/security/get-users.asciidoc @@ -52,14 +52,13 @@ If the user is not defined in the `native` realm, the request 404s. To retrieve a native user, submit a GET request to the `/_security/user/` endpoint: -[source,js] +[source,console] -------------------------------------------------- GET /_security/user/jacknich -------------------------------------------------- -// CONSOLE // TEST[setup:jacknich_user] -[source,js] +[source,console-result] -------------------------------------------------- { "jacknich": { @@ -74,14 +73,11 @@ GET /_security/user/jacknich } } -------------------------------------------------- -// CONSOLE -// TESTRESPONSE Omit the username to retrieve all users: -[source,js] +[source,console] -------------------------------------------------- GET /_security/user -------------------------------------------------- -// CONSOLE // TEST[continued] diff --git a/x-pack/docs/en/rest-api/security/has-privileges.asciidoc b/x-pack/docs/en/rest-api/security/has-privileges.asciidoc index f211c8df6331f..cce21965d6e30 100644 --- a/x-pack/docs/en/rest-api/security/has-privileges.asciidoc +++ b/x-pack/docs/en/rest-api/security/has-privileges.asciidoc @@ -64,7 +64,7 @@ should be checked The following example checks whether the current user has a specific set of cluster, index, and application privileges: -[source,js] +[source,console] -------------------------------------------------- GET /_security/user/_has_privileges { @@ -88,11 +88,10 @@ GET /_security/user/_has_privileges ] } -------------------------------------------------- -// CONSOLE The following example output indicates which privileges the "rdeniro" user has: -[source,js] +[source,console-result] -------------------------------------------------- { "username": "rdeniro", diff --git a/x-pack/docs/en/rest-api/security/invalidate-api-keys.asciidoc b/x-pack/docs/en/rest-api/security/invalidate-api-keys.asciidoc index ecd79a0906cfd..a9453cb53577a 100644 --- a/x-pack/docs/en/rest-api/security/invalidate-api-keys.asciidoc +++ b/x-pack/docs/en/rest-api/security/invalidate-api-keys.asciidoc @@ -68,20 +68,18 @@ keys. If you create an API key as follows: -[source, js] +[source,console] ------------------------------------------------------------ POST /_security/api_key { "name": "my-api-key" } ------------------------------------------------------------ -// CONSOLE -// TEST A successful call returns a JSON structure that provides API key information. For example: -[source,js] +[source,console-result] -------------------------------------------------- { "id":"VuaCfGcBCdbkQm-e5aOx", @@ -95,60 +93,53 @@ API key information. For example: The following example invalidates the API key identified by specified `id` immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/api_key { "id" : "VuaCfGcBCdbkQm-e5aOx" } -------------------------------------------------- -// CONSOLE // TEST[s/VuaCfGcBCdbkQm-e5aOx/$body.id/] // TEST[continued] The following example invalidates the API key identified by specified `name` immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/api_key { "name" : "my-api-key" } -------------------------------------------------- -// CONSOLE -// TEST The following example invalidates all API keys for the `native1` realm immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/api_key { "realm_name" : "native1" } -------------------------------------------------- -// CONSOLE -// TEST The following example invalidates all API keys for the user `myuser` in all realms immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/api_key { "username" : "myuser" } -------------------------------------------------- -// CONSOLE -// TEST The following example invalidates the API key identified by the specified `id` if it is owned by the currently authenticated user immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/api_key { @@ -156,25 +147,22 @@ DELETE /_security/api_key "owner" : "true" } -------------------------------------------------- -// CONSOLE The following example invalidates all API keys owned by the currently authenticated user immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/api_key { "owner" : "true" } -------------------------------------------------- -// CONSOLE -// TEST Finally, the following example invalidates all API keys for the user `myuser` in the `native1` realm immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/api_key { @@ -182,8 +170,6 @@ DELETE /_security/api_key "realm_name" : "native1" } -------------------------------------------------- -// CONSOLE -// TEST [source,js] -------------------------------------------------- diff --git a/x-pack/docs/en/rest-api/security/invalidate-tokens.asciidoc b/x-pack/docs/en/rest-api/security/invalidate-tokens.asciidoc index 91f9b1e1bfd81..d4da53ebbe5c4 100644 --- a/x-pack/docs/en/rest-api/security/invalidate-tokens.asciidoc +++ b/x-pack/docs/en/rest-api/security/invalidate-tokens.asciidoc @@ -68,19 +68,17 @@ and potentially a list of errors encountered while invalidating specific tokens. For example, if you create a token using the `client_credentials` grant type as follows: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oauth2/token { "grant_type" : "client_credentials" } -------------------------------------------------- -// CONSOLE -// TEST The get token API returns the following information about the access token: -[source,js] +[source,console-result] -------------------------------------------------- { "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==", @@ -88,27 +86,25 @@ The get token API returns the following information about the access token: "expires_in" : 1200 } -------------------------------------------------- -// CONSOLE // TESTRESPONSE[s/dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==/$body.access_token/] This access token can now be immediately invalidated, as shown in the following example: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/oauth2/token { "token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==" } -------------------------------------------------- -// CONSOLE // TEST[s/dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==/$body.access_token/] // TEST[continued] If you used the `password` grant type to obtain a token for a user, the response might also contain a refresh token. For example: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oauth2/token { @@ -117,12 +113,10 @@ POST /_security/oauth2/token "password" : "x-pack-test-password" } -------------------------------------------------- -// CONSOLE -// TEST The get token API returns the following information: -[source,js] +[source,console-result] -------------------------------------------------- { "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==", @@ -131,54 +125,48 @@ The get token API returns the following information: "refresh_token": "vLBPvmAB6KvwvJZr27cS" } -------------------------------------------------- -// CONSOLE // TESTRESPONSE[s/dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==/$body.access_token/] // TESTRESPONSE[s/vLBPvmAB6KvwvJZr27cS/$body.refresh_token/] The refresh token can now also be immediately invalidated as shown in the following example: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/oauth2/token { "refresh_token" : "vLBPvmAB6KvwvJZr27cS" } -------------------------------------------------- -// CONSOLE // TEST[s/vLBPvmAB6KvwvJZr27cS/$body.refresh_token/] // TEST[continued] The following example invalidates all access tokens and refresh tokens for the `saml1` realm immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/oauth2/token { "realm_name" : "saml1" } -------------------------------------------------- -// CONSOLE -// TEST The following example invalidates all access tokens and refresh tokens for the user `myuser` in all realms immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/oauth2/token { "username" : "myuser" } -------------------------------------------------- -// CONSOLE -// TEST Finally, the following example invalidates all access tokens and refresh tokens for the user `myuser` in the `saml1` realm immediately: -[source,js] +[source,console] -------------------------------------------------- DELETE /_security/oauth2/token { @@ -186,8 +174,6 @@ DELETE /_security/oauth2/token "realm_name" : "saml1" } -------------------------------------------------- -// CONSOLE -// TEST [source,js] -------------------------------------------------- diff --git a/x-pack/docs/en/rest-api/security/oidc-authenticate-api.asciidoc b/x-pack/docs/en/rest-api/security/oidc-authenticate-api.asciidoc index 67e6d68a109ec..0814257d3aefa 100644 --- a/x-pack/docs/en/rest-api/security/oidc-authenticate-api.asciidoc +++ b/x-pack/docs/en/rest-api/security/oidc-authenticate-api.asciidoc @@ -61,7 +61,7 @@ OpenID Connect Provider after a successful authentication, for an {es} access token and refresh token to be used in subsequent requests. This example is from an authentication that uses the authorization code grant flow. -[source,js] +[source,console] -------------------------------------------------- POST /_security/oidc/authenticate { @@ -71,7 +71,6 @@ POST /_security/oidc/authenticate "realm" : "oidc1" } -------------------------------------------------- -// CONSOLE // TEST[catch:unauthorized] The following example output contains the access token that was generated in diff --git a/x-pack/docs/en/rest-api/security/oidc-logout-api.asciidoc b/x-pack/docs/en/rest-api/security/oidc-logout-api.asciidoc index 47d7125b94d99..0b6ef70302626 100644 --- a/x-pack/docs/en/rest-api/security/oidc-logout-api.asciidoc +++ b/x-pack/docs/en/rest-api/security/oidc-logout-api.asciidoc @@ -40,7 +40,7 @@ and The following example performs logout -[source,js] +[source,console] -------------------------------------------------- POST /_security/oidc/logout { @@ -48,7 +48,6 @@ POST /_security/oidc/logout "refresh_token": "vLBPvmAB6KvwvJZr27cS" } -------------------------------------------------- -// CONSOLE // TEST[catch:unauthorized] The following example output of the response contains the URI pointing to the diff --git a/x-pack/docs/en/rest-api/security/oidc-prepare-authentication-api.asciidoc b/x-pack/docs/en/rest-api/security/oidc-prepare-authentication-api.asciidoc index daf1854e81f88..424ed51742f8f 100644 --- a/x-pack/docs/en/rest-api/security/oidc-prepare-authentication-api.asciidoc +++ b/x-pack/docs/en/rest-api/security/oidc-prepare-authentication-api.asciidoc @@ -65,19 +65,18 @@ parameter is not valid when `realm` is specified The following example generates an authentication request for the OpenID Connect Realm `oidc1`: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oidc/prepare { "realm" : "oidc1" } -------------------------------------------------- -// CONSOLE The following example output of the response contains the URI pointing to the Authorization Endpoint of the OpenID Connect Provider with all the parameters of the Authentication Request, as HTTP GET parameters: -[source,js] +[source,console-result] -------------------------------------------------- { "redirect" : "http://127.0.0.1:8080/c2id-login?scope=openid&response_type=id_token&redirect_uri=https%3A%2F%2Fmy.fantastic.rp%2Fcb&state=4dbrihtIAt3wBTwo6DxK-vdk-sSyDBV8Yf0AjdkdT5I&nonce=WaBPH0KqPVdG5HHdSxPRjfoZbXMCicm5v1OiAj0DUFM&client_id=elasticsearch-rp", @@ -92,7 +91,7 @@ The following example generates an authentication request for the OpenID Connect Realm `oidc1`, where the values for the state and the nonce have been generated by the client: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oidc/prepare { @@ -101,12 +100,11 @@ POST /_security/oidc/prepare "nonce" : "zOBXLJGUooRrbLbQk5YCcyC8AXw3iloynvluYhZ5" } -------------------------------------------------- -// CONSOLE The following example output of the response contains the URI pointing to the Authorization Endpoint of the OpenID Connect Provider with all the parameters of the Authentication Request, as HTTP GET parameters: -[source,js] +[source,console-result] -------------------------------------------------- { "redirect" : "http://127.0.0.1:8080/c2id-login?scope=openid&response_type=id_token&redirect_uri=https%3A%2F%2Fmy.fantastic.rp%2Fcb&state=lGYK0EcSLjqH6pkT5EVZjC6eIW5YCGgywj2sxROO&nonce=zOBXLJGUooRrbLbQk5YCcyC8AXw3iloynvluYhZ5&client_id=elasticsearch-rp", @@ -114,13 +112,12 @@ the Authentication Request, as HTTP GET parameters: "nonce" : "zOBXLJGUooRrbLbQk5YCcyC8AXw3iloynvluYhZ5" } -------------------------------------------------- -// TESTRESPONSE The following example generates an authentication request for a 3rd party initiated single sign on, specifying the issuer that should be used for matching the appropriate OpenID Connect Authentication realm: -[source,js] +[source,console] -------------------------------------------------- POST /_security/oidc/prepare { @@ -128,12 +125,11 @@ POST /_security/oidc/prepare "login_hint": "this_is_an_opaque_string" } -------------------------------------------------- -// CONSOLE The following example output of the response contains the URI pointing to the Authorization Endpoint of the OpenID Connect Provider with all the parameters of the Authentication Request, as HTTP GET parameters: -[source,js] +[source,console-result] -------------------------------------------------- { "redirect" : "http://127.0.0.1:8080/c2id-login?login_hint=this_is_an_opaque_string&scope=openid&response_type=id_token&redirect_uri=https%3A%2F%2Fmy.fantastic.rp%2Fcb&state=4dbrihtIAt3wBTwo6DxK-vdk-sSyDBV8Yf0AjdkdT5I&nonce=WaBPH0KqPVdG5HHdSxPRjfoZbXMCicm5v1OiAj0DUFM&client_id=elasticsearch-rp", diff --git a/x-pack/docs/en/rest-api/security/put-app-privileges.asciidoc b/x-pack/docs/en/rest-api/security/put-app-privileges.asciidoc index 494171492127c..c048e19a18c28 100644 --- a/x-pack/docs/en/rest-api/security/put-app-privileges.asciidoc +++ b/x-pack/docs/en/rest-api/security/put-app-privileges.asciidoc @@ -86,7 +86,7 @@ been created or updated. To add a single privilege, submit a PUT or POST request to the `/_security/privilege//` endpoint. For example: -[source,js] +[source,console] -------------------------------------------------- PUT /_security/privilege { @@ -102,7 +102,6 @@ PUT /_security/privilege } } -------------------------------------------------- -// CONSOLE <1> These strings have significance within the "myapp" application. {es} does not assign any meaning to them. <2> The use of a wildcard here (`*`) means that this privilege grants access to @@ -113,7 +112,7 @@ PUT /_security/privilege wildcard and returns `true`. <3> The metadata object is optional. -[source,js] +[source,console-result] -------------------------------------------------- { "myapp": { @@ -123,13 +122,12 @@ PUT /_security/privilege } } -------------------------------------------------- -// TESTRESPONSE <1> When an existing privilege is updated, `created` is set to false. To add multiple privileges, submit a POST request to the `/_security/privilege/` endpoint. For example: -[source,js] +[source,console] -------------------------------------------------- PUT /_security/privilege { @@ -148,12 +146,11 @@ PUT /_security/privilege } } -------------------------------------------------- -// CONSOLE A successful call returns a JSON structure that shows whether the privileges have been created or updated. -[source,js] +[source,console-result] -------------------------------------------------- { "app02": { @@ -171,4 +168,3 @@ have been created or updated. } } -------------------------------------------------- -// TESTRESPONSE diff --git a/x-pack/docs/en/rest-api/security/ssl.asciidoc b/x-pack/docs/en/rest-api/security/ssl.asciidoc index ad0ff9e5a0f39..4263bce006772 100644 --- a/x-pack/docs/en/rest-api/security/ssl.asciidoc +++ b/x-pack/docs/en/rest-api/security/ssl.asciidoc @@ -80,12 +80,10 @@ certificate, this field has a value of `true`. The following example provides information about the certificates on a single node of {es}: -[source,js] +[source,console] -------------------------------------------------- GET /_ssl/certificates -------------------------------------------------- -// CONSOLE -// TEST The API returns the following results: