honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[DOCS] Update snippets in security APIs (#46191) (#46401)

This commit is contained in:
Lisa Cawley 2019-09-05 11:12:39 -07:00 committed by GitHub
parent caf3e4d654
commit 828ff01515
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
30 changed files with 99 additions and 203 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
x-pack/docs/en/rest-api/security/authenticate.asciidoc
View File

@ -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",

6
x-pack/docs/en/rest-api/security/change-password.asciidoc
View File

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

9
x-pack/docs/en/rest-api/security/clear-cache.asciidoc
View File

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

3
x-pack/docs/en/rest-api/security/clear-roles-cache.asciidoc
View File

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

5
x-pack/docs/en/rest-api/security/create-api-keys.asciidoc
View File

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

30
x-pack/docs/en/rest-api/security/create-role-mappings.asciidoc
View File

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

6
x-pack/docs/en/rest-api/security/create-roles.asciidoc
View File

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

6
x-pack/docs/en/rest-api/security/create-users.asciidoc
View File

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

5
x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc
View File

@ -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==",

7
x-pack/docs/en/rest-api/security/delete-app-privileges.asciidoc
View File

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

6
x-pack/docs/en/rest-api/security/delete-role-mappings.asciidoc
View File

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

6
x-pack/docs/en/rest-api/security/delete-roles.asciidoc
View File

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

6
x-pack/docs/en/rest-api/security/delete-users.asciidoc
View File

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

3
x-pack/docs/en/rest-api/security/disable-users.asciidoc
View File

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

3
x-pack/docs/en/rest-api/security/enable-users.asciidoc
View File

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

30
x-pack/docs/en/rest-api/security/get-api-keys.asciidoc
View File

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

12
x-pack/docs/en/rest-api/security/get-app-privileges.asciidoc
View File

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

7
x-pack/docs/en/rest-api/security/get-builtin-privileges.asciidoc
View File

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

6
x-pack/docs/en/rest-api/security/get-role-mappings.asciidoc
View File

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

9
x-pack/docs/en/rest-api/security/get-roles.asciidoc
View File

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

15
x-pack/docs/en/rest-api/security/get-tokens.asciidoc
View File

@ -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==",

10
x-pack/docs/en/rest-api/security/get-users.asciidoc
View File

@ -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/<username>`
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]

5
x-pack/docs/en/rest-api/security/has-privileges.asciidoc
View File

@ -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",

32
x-pack/docs/en/rest-api/security/invalidate-api-keys.asciidoc
View File

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

32
x-pack/docs/en/rest-api/security/invalidate-tokens.asciidoc
View File

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

3
x-pack/docs/en/rest-api/security/oidc-authenticate-api.asciidoc
View File

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

3
x-pack/docs/en/rest-api/security/oidc-logout-api.asciidoc
View File

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

16
x-pack/docs/en/rest-api/security/oidc-prepare-authentication-api.asciidoc
View File

@ -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",

12
x-pack/docs/en/rest-api/security/put-app-privileges.asciidoc
View File

@ -86,7 +86,7 @@ been created or updated.
To add a single privilege, submit a PUT or POST request to the
`/_security/privilege/<application>/<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

4
x-pack/docs/en/rest-api/security/ssl.asciidoc
View File

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