elasticsearch/docs/reference/security/authentication/security-domain.asciidoc
James Rodewig 255c9a7f95
[DOCS] Move x-pack docs to docs/reference dir (#99209)
**Problem:**
For historical reasons, source files for the Elasticsearch Guide's security, watcher, and Logstash API docs are housed in the `x-pack/docs` directory. This can confuse new contributors who expect Elasticsearch Guide docs to be located in `docs/reference`. 

**Solution:**
- Move the security, watcher, and Logstash API doc source files to the `docs/reference` directory
- Update doc snippet tests to use security

Rel: https://github.com/elastic/platform-docs-team/issues/208
2023-09-12 14:53:41 -04:00

137 lines
6.4 KiB
Text

[role="xpack"]
[[security-domain]]
=== Security domains
Security domains are a method of grouping multiple <<realms,realms>> under the
same domain so that the {stack} can recognize when a single user authenticates
with these realms. Users can authenticate with any of the realms in the domain
group, and have access to the same set of resources regardless of which realm
they authenticated with.
For example, a single <<user-profile,user profile>> is associated with a user,
enabling preferences, notifications, and other user data to be shared across
realms. The user can view results from an asynchronous search request or a
scrolling search across realms. If the user has the necessary privileges, they
can also view and manage API keys across realms.
[[security-domain-resource-sharing]]
==== Resource sharing across domains
Some types of resources in {es} are owned by a single user, such as
<<async-search,async search contexts>>, <<security-api-create-api-key,API keys>>,
and <<user-profile,user profiles>>. When a user creates a resource, {es}
captures the user's username and realm information as part of the resource's
metadata. Likewise, if a user updates a resource, such as an API key,
{es} automatically re-captures the user's current realm information.
When a user later attempts to access the resource, {es} compares
the captured username and realm information against those from the accessing
user. {es} will deny access unless both the realm and username match.
If {es} detects that a username from two different realms is
attempting to access a resource, {es} assumes that these users are distinct and
doesn't allow resources to be shared between those users.
However, there are cases where the same user can authenticate with
multiple realms and needs to share the same set of resources across realms.
For example, an <<ldap-realm,LDAP realm>> and a <<saml-realm,SAML realm>> can
be backed by the same directory service. Additionally,
<<configuring-authorization-delegation,authorization delegation>> allows one
realm to delegate authorization to another realm. If both realms authenticate
users with the same username, it's reasonable to treat these users as the
same user from a resource ownership perspective.
Security domains make resource sharing across realms possible by grouping those
realms under the same domain. {es} always enforces the privileges that are
associated with the currently authenticated user, which remains true with
security domains. Security domains don't bypass
<<authorization,user authorization>> when resource sharing requires them. For
example, a user requires the `manage_own_api_key` privilege to manage their own
API keys. If that user doesn't have this privilege when authenticating with one
realm, they won't be able to manage API keys while authenticating with another
realm.
[[security-domain-realm-roles]]
===== Managing roles across realms
{es} provides multiple ways to consistently apply roles across realms. For example, you can use
<<configuring-authorization-delegation,authorization delegation>> to
ensure that a user is assigned the same roles from multiple realms. You can also
manually configure multiple realms that are backed by the same directory service.
Though it's possible to configure different <<roles,roles>> for the same user
when authenticating with different realms, it is _not_ recommended.
[[security-domain-configure]]
==== Configure a security domain
[[security-domain-warning]]
[IMPORTANT]
====
Security domains are an advanced feature that requires careful configuration.
Misconfiguration or misuse can lead to unexpected behaviors.
====
Security domains must be configured consistently across all nodes in cluster.
Inconsistent configuration can lead to issues such as:
- Duplicated user profiles
- Different ownership of resources depending on the authenticating node's configuration
To configure a security domain:
. Add a security domain configuration to `elasticsearch.yml` in the
`xpack.security.authc.domains` namespace:
+
[source, yaml]
----
xpack:
security:
authc:
domains:
my_domain:
realms: [ 'default_native', 'saml1' ] <1>
----
<1> This configuration defines a security domain called `my_domain`, which
contains two realms named `default_native` and `saml1`.
+
The specified realms must be defined in `elasticsearch.yml`,
but do not need to be enabled.
+
NOTE: The <<file-realm,file realm>> and <<native-realm,native realm>> are
automatically enabled as `default_file` and `default_native`, respectively,
without any explicit configuration. You can list these realms under domains even
when they are not explicitly defined in `elasticsearch.yml`.
. Restart {es}.
+
[IMPORTANT]
====
{es} can fail to start if the domain configuration is invalid, such as:
* The same realm is configured under multiple domains.
* Any undefined realm, synthetic realm, or the reserved realm is configured to
be under a domain.
====
. Apply the same configuration across all nodes in the cluster
before performing operations related to security domains,
including creating and managing resources such as
<<user-profile,user profiles>>, <<security-api-create-api-key,API keys>>, and <<async-search,async search>>.
+
When adding realms to a security domain, avoid authenticating with a newly-added realm until changes are fully applied to all nodes.
[[security-domain-remove-realm]]
==== Removing realms from a security domain
Removing realms from a security domain can lead to unexpected behaviors
and is not recommended.
Resources created or updated before the removal can be owned by different users depending on the resource type:
- <<user-profile,User profiles>> are owned by the user for whom the profile was last
<<security-api-activate-user-profile,activated>>.
For users whose realms are no longer in the same domain as the owner user, a new user profile
will be created for them next time the activate user profile API is called.
- An API key is owned by the user who originally <<security-api-create-api-key,created>> or last <<security-api-update-api-key,updated>> it.
Users, including the original creator of the API key, will lose ownership if their realms are no longer in the same domain as those of the current API key owner.
- Resources such as async search contexts are owned by the user who originally created them.
Instead of removing realms, consider disabling them and keeping them as part of the security domain.
Under all circumstances, resource sharing across realms is only possible between users with the same username.