openstack/openstack-manuals
Code Issues Proposed changes

Convert other Identity files to RST

Browse Source 
Files converted:
- Integrate Identity with LDAP
- Use trusts
- Configure Identity service for token binding
- Caching layer
- Integrate assignment back end with LDAP
- Integrate Identity back end with LDAP
- Secure the Identity service connection to an LDAP back end

Change-Id: Ic51e1a677993eabaaa6316df61ec5517cfeb99a4
Implements: blueprint reorganise-user-guide
This commit is contained in:
daz
2015-06-23 16:56:53 +10:00
parent 6a9f926c60
commit 673edd8504
8 changed files with 907 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
doc/admin-guide-cloud-rst/source/identity_management.rst
View File

@@ -247,16 +247,6 @@ resulting file would look like:
"network:delete_dns_domain": "role:compute-user" "network:delete_dns_domain": "role:compute-user"
} }
.. TODO (DC) Convert the following common files and include(?) them as
sections:
/common/section_keystone_certificates-for-pki.xml
/common/section_keystone-ssl-config.xml
/common/section_keystone-external-auth.xml
/common/section_keystone_config_ldap.xml
identity/section_keystone-token-binding.xml
identity/section_keystone-trusts.xml
identity/section_caching-layer.xml
Service management Service management
------------------ ------------------
@@ -330,18 +320,31 @@ Here are a couple of examples:
Domain B, if User B gets a token scoped to Domain B, the token also Domain B, if User B gets a token scoped to Domain B, the token also
includes Role B. includes Role B.
.. include:: keystone_certificates_for_pki.rst .. include:: keystone_certificates_for_pki.rst
.. include:: keystone_configure_with_SSL.rst .. include:: keystone_configure_with_SSL.rst
.. include:: keystone_external_authentication.rst .. include:: keystone_external_authentication.rst
.. include:: keystone_integrate_with_ldap.rst
.. include:: keystone_token-binding.rst
.. include:: keystone_use_trusts.rst
.. include:: keystone_caching_layer.rst
.. toctree:: .. toctree::
:hidden: :hidden:
keystone_certificates_for_pki.rst keystone_certificates_for_pki.rst
keystone_configure_with_SSL.rst keystone_configure_with_SSL.rst
keystone_external_authentication.rst keystone_external_authentication.rst
keystone_integrate_with_ldap.rst
keystone_token-binding.rst
keystone_use_trusts.rst
keystone_caching_layer.rst
User CRUD User CRUD
~~~~~~~~~ ~~~~~~~~~

135
doc/admin-guide-cloud-rst/source/keystone_caching_layer.rst Normal file
View File

@@ -0,0 +1,135 @@
.. :orphan:
Caching layer
~~~~~~~~~~~~~
OpenStack Identity supports a caching layer that is above the
configurable subsystems (for example, token, assignment). OpenStack
Identity uses the
`dogpile.cache <http://dogpilecache.readthedocs.org/en/latest/>`__
library which allows flexible cache back ends. The majority of the
caching configuration options are set in the ``[cache]`` section of the
:file:`keystone.conf` file. However, each section that has the capability to
be cached usually has a caching boolean value that toggles caching.
So to enable only the token back end caching, set the values as follows:
.. code-block:: ini
:linenos:
[cache]
enabled=true
[assignment]
caching=false
[token]
caching=true
.. note::
Since the Juno release, the default setting is enabled for subsystem
caching, but the global toggle is disabled. As a result, no caching
in available unless the global toggle for ``[cache]`` is enabled by
setting the value to ``true``.
Caching for tokens and tokens validation
----------------------------------------
The token system has a separate ``cache_time`` configuration option,
that can be set to a value above or below the global ``expiration_time``
default, allowing for different caching behavior from the other systems
in OpenStack Identity. This option is set in the ``[token]`` section of
the configuration file.
The token revocation list cache time is handled by the configuration
option ``revocation_cache_time`` in the ``[token]`` section. The
revocation list is refreshed whenever a token is revoked. It typically
sees significantly more requests than specific token retrievals or token
validation calls.
Here is a list of actions that are affected by the cached time: getting
a new token, revoking tokens, validating tokens, checking v2 tokens, and
checking v3 tokens.
The delete token API calls invalidate the cache for the tokens being
acted upon, as well as invalidating the cache for the revoked token list
and the validate/check token calls.
Token caching is configurable independently of the ``revocation_list``
caching. Lifted expiration checks from the token drivers to the token
manager. This ensures that cached tokens will still raise a
``TokenNotFound`` flag when expired.
For cache consistency, all token IDs are transformed into the short
token hash at the provider and token driver level. Some methods have
access to the full ID (PKI Tokens), and some methods do not. Cache
invalidation is inconsistent without token ID normalization.
Caching around assignment CRUD
------------------------------
The assignment system has a separate ``cache_time`` configuration
option, that can be set to a value above or below the global
``expiration_time`` default, allowing for different caching behavior
from the other systems in Identity service. This option is set in the
``[assignment]`` section of the configuration file.
Currently ``assignment`` has caching for ``project``, ``domain``, and
``role`` specific requests (primarily around the CRUD actions). Caching
is currently not implemented on grants. The ``list`` methods are not
subject to caching.
Here is a list of actions that are affected by the assignment: assign
domain API, assign project API, and assign role API.
The create, update, and delete actions for domains, projects and roles
will perform proper invalidations of the cached methods listed above.
.. note::
If a read-only ``assignment`` back end is in use, the cache will not
immediately reflect changes on the back end. Any given change may
take up to the ``cache_time`` (if set in the ``[assignment]``
section of the configuration file) or the global ``expiration_time``
(set in the ``[cache]`` section of the configuration file) before it
is reflected. If this type of delay (when using a read-only
``assignment`` back end) is an issue, it is recommended that caching
be disabled on ``assignment``. To disable caching specifically on
``assignment``, in the ``[assignment]`` section of the configuration
set ``caching`` to ``False``.
For more information about the different back ends (and configuration
options), see:
- `dogpile.cache.backends.memory <http://dogpilecache.readthedocs.org/en/latest/api.html#memory-backend>`__
- `dogpile.cache.backends.memcached <http://dogpilecache.readthedocs.org/en/latest/api.html#memcached-backends>`__
.. note::
The memory back end is not suitable for use in a production
environment.
- `dogpile.cache.backends.redis <http://dogpilecache.readthedocs.org/en/latest/api.html#redis-backends>`__
- `dogpile.cache.backends.file <http://dogpilecache.readthedocs.org/en/latest/api.html#file-backends>`__
- ``keystone.common.cache.backends.mongo``
Configure the Memcached back end example
----------------------------------------
The following example shows how to configure the memcached back end:
.. code-block:: ini
:linenos:
[cache]
enabled = true
backend = dogpile.cache.memcached
backend_argument = url:127.0.0.1:11211
You need to specify the URL to reach the ``memcached`` instance with the
``backend_argument`` parameter.

148
doc/admin-guide-cloud-rst/source/keystone_integrate_assignment_backend_ldap.rst Normal file
View File

@@ -0,0 +1,148 @@
Integrate assignment back end with LDAP
---------------------------------------
When you configure the OpenStack Identity service to use LDAP servers,
you can split authentication and authorization using the *assignment*
feature. Integrating the assignment back end with LDAP allows
administrators to use projects (tenant), roles, domains, and role
assignments in LDAP.
.. note::
Using LDAP as an assignment back end is not recommended.
.. note::
The OpenStack Identity service does not support domain-specific
assignment back ends.
.. important::
For OpenStack Identity assignments to access LDAP servers, you must
define the destination LDAP server in the :file:`keystone.conf` file.
For more information, see ?.
.. TODO (DC) Add link to keystone_integrate_identity_with_ldap.rst
**Integrating assignment back ends with LDAP**
#. Enable the assignment driver. In the ``[assignment]`` section, set the
``driver`` configuration key to
``keystone.assignment.backends.sql.Assignment``:
.. code-block:: ini
:linenos:
[assignment]
#driver = keystone.assignment.backends.sql.Assignment
driver = keystone.assignment.backends.ldap.Assignment
#. Create the organizational units (OU) in the LDAP directory, and define
their corresponding location in the ``keystone.conf`` file:
.. code-block:: ini
:linenos:
[ldap]
role_tree_dn =
role_objectclass = inetOrgPerson
project_tree_dn = ou=Groups,dc=example,dc=org
project_objectclass = groupOfNames
.. note::
These schema attributes are extensible for compatibility with
various schemas. For example, this entry maps to the groupOfNames
attribute in Active Directory:
.. code:: ini
project_objectclass = groupOfNames
#. A read-only implementation is recommended for LDAP integration. These
permissions are applied to object types in the ``keystone.conf`` file:
.. code-block:: ini
:linenos:
[ldap]
role_allow_create = False
role_allow_update = False
role_allow_delete = False
project_allow_create = False
project_allow_update = False
project_allow_delete = False
#. Restart the OpenStack Identity service::
# service keystone restart
.. warning::
During service restart, authentication and authorization are
unavailable.
**Additional LDAP integration settings.**
Set these options in the :file:`/etc/keystone/keystone.conf` file for a
single LDAP server, or :file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf`
files for multiple back ends.
Filters
Use filters to control the scope of data presented through LDAP.
.. code-block:: ini
:linenos:
[ldap]
project_filter = (member=cn=openstack-user,ou=workgroups,
dc=example,dc=org)
role_filter =
.. warning::
Filtering method
Assignment attribute mapping
Mask account status values (include any additional attribute
mappings) for compatibility with various directory services.
Superfluous accounts are filtered with user\_filter.
Setting attribute ignore to list of attributes stripped off on
update.
.. code-block:: ini
:linenos:
[ldap]
role_id_attribute = cn
role_name_attribute = ou
role_member_attribute = roleOccupant
role_additional_attribute_mapping =
role_attribute_ignore =
project_id_attribute = cn
project_name_attribute = ou
project_member_attribute = member
project_desc_attribute = description
project_enabled_attribute = enabled
project_domain_id_attribute = businessCategory
project_additional_attribute_mapping =
project_attribute_ignore =
Enabled emulation
An alternative method to determine if a project is enabled or not is
to check if that project is a member of the emulation group.
Use DN of the group entry to hold enabled projects when using
enabled emulation.
.. code-block:: ini
:linenos:
[ldap]
project_enabled_emulation = false
project_enabled_emulation_dn = false

241
doc/admin-guide-cloud-rst/source/keystone_integrate_identity_backend_ldap.rst Normal file
View File

@@ -0,0 +1,241 @@
Integrate Identity back end with LDAP
-------------------------------------
The Identity back end contains information for users, groups, and group
member lists. Integrating the Identity back end with LDAP allows
administrators to use users and groups in LDAP.
.. important::
For OpenStack Identity Service to access LDAP servers, you must
define the destination LDAP server in the ``keystone.conf`` file.
For more information, see ?.
.. TODO (DC) Add link to keystone_integrate_identity_with_ldap.rst
**Integrating an Identity back end with LDAP**
#. Enable the LDAP Identity driver in the ``keystone.conf`` file. This
allows LDAP as an identity back end:
.. code-block:: ini
:linenos:
[identity]
#driver = keystone.identity.backends.sql.Identity
driver = keystone.identity.backends.ldap.Identity
#. Create the organizational units (OU) in the LDAP directory, and define
the corresponding location in the :file:`keystone.conf` file:
.. code-block:: ini
:linenos:
[ldap]
user_tree_dn = ou=Users,dc=example,dc=org
user_objectclass = inetOrgPerson
group_tree_dn = ou=Groups,dc=example,dc=org
group_objectclass = groupOfNames
.. note::
These schema attributes are extensible for compatibility with
various schemas. For example, this entry maps to the person
attribute in Active Directory:
.. code:: ini
user_objectclass = person
#. A read-only implementation is recommended for LDAP integration. These
permissions are applied to object types in the :file:`keystone.conf`:
.. code-block:: ini
:linenos:
[ldap]
user_allow_create = False
user_allow_update = False
user_allow_delete = False
group_allow_create = False
group_allow_update = False
group_allow_delete = False
Restart the OpenStack Identity service::
# service keystone restart
.. warning::
During service restart, authentication and authorization are
unavailable.
**Integrating Identity with multiple back ends**
#. Set the following options in the :file:`/etc/keystone/keystone.conf` file:
#. Enable the LDAP driver:
.. code:: ini
[identity]
#driver = keystone.identity.backends.sql.Identity
driver = keystone.identity.backends.ldap.Identity
#. Enable domain-specific drivers:
.. code:: ini
[identity]
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains
#. Restart the service::
# service keystone restart
#. List the domains using the dashboard, or the OpenStackClient CLI. Refer
to the `Command List
<http://docs.openstack.org/developer/python-openstackclient/command-list.html>`__
for a list of OpenStackClient commands.
#. Create domains using OpenStack dashboard, or the OpenStackClient CLI.
#. For each domain, create a domain-specific configuration file in the
:file:`/etc/keystone/domains` directory. Use the file naming convention
:file:`keystone.DOMAIN_NAME.conf`, where DOMAIN\_NAME is the domain name
assigned in the previous step.
.. note::
The options set in the
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file will
override options in the :file:`/etc/keystone/keystone.conf` file.
#. Define the destination LDAP server in the
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file. For example:
.. code-block:: ini
:linenos:
[ldap]
url = ldap://localhost
user = dc=Manager,dc=example,dc=org
password = samplepassword
suffix = dc=example,dc=org
use_dumb_member = False
allow_subtree_delete = False
#. Create the organizational units (OU) in the LDAP directories, and define
their corresponding locations in the
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file. For example:
.. code-block:: ini
:linenos:
[ldap]
user_tree_dn = ou=Users,dc=example,dc=org
user_objectclass = inetOrgPerson
group_tree_dn = ou=Groups,dc=example,dc=org
group_objectclass = groupOfNames
.. note::
These schema attributes are extensible for compatibility with
various schemas. For example, this entry maps to the person
attribute in Active Directory:
.. code:: ini
user_objectclass = person
#. A read-only implementation is recommended for LDAP integration. These
permissions are applied to object types in the
:file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf` file:
.. code:: ini
[ldap]
user_allow_create = False
user_allow_update = False
user_allow_delete = False
group_allow_create = False
group_allow_update = False
group_allow_delete = False
#. Restart the OpenStack Identity service::
# service keystone restart
.. warning::
During service restart, authentication and authorization are
unavailable.
**Additional LDAP integration settings.**
Set these options in the :file:`/etc/keystone/keystone.conf` file for a
single LDAP server, or :file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf`
files for multiple back ends.
Filters
Use filters to control the scope of data presented through LDAP.
.. code-block:: ini
:linenos:
[ldap]
user_filter = (memberof=cn=openstack-users,ou=workgroups,dc=example,dc=org)
group_filter =
Identity attribute mapping
Mask account status values (include any additional attribute
mappings) for compatibility with various directory services.
Superfluous accounts are filtered with ``user_filter``.
Setting attribute ignore to list of attributes stripped off on
update.
For example, you can mask Active Directory account status attributes
in the :file:`keystone.conf` file:
.. code-block:: ini
:linenos:
[ldap]
user_id_attribute = cn
user_name_attribute = sn
user_mail_attribute = mail
user_pass_attribute = userPassword
user_enabled_attribute = userAccountControl
user_enabled_mask = 2
user_enabled_invert = false
user_enabled_default = 51
user_default_project_id_attribute =
user_attribute_ignore = default_project_id,tenants
user_additional_attribute_mapping =
group_id_attribute = cn
group_name_attribute = ou
group_member_attribute = member
group_desc_attribute = description
group_attribute_ignore =
group_additional_attribute_mapping =
Enabled emulation
An alternative method to determine if a user is enabled or not is by
checking if that user is a member of the emulation group.
Use DN of the group entry to hold enabled user when using enabled
emulation.
.. code-block:: ini
:linenos:
[ldap]
user_enabled_emulation = false
user_enabled_emulation_dn = false

173
doc/admin-guide-cloud-rst/source/keystone_integrate_with_ldap.rst Normal file
View File

@@ -0,0 +1,173 @@
.. _integrate-identity-with-ldap:
.. :orphan:
Integrate Identity with LDAP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The OpenStack Identity service supports integration with existing LDAP
directories for authentication and authorization services.
When the OpenStack Identity service is configured to use LDAP back ends,
you can split authentication (using the *identity* feature) and
authorization (using the *assignment* feature).
The *identity* feature enables administrators to manage users and groups
by each domain or the OpenStack Identity service entirely.
The *assignment* feature enables administrators to manage project role
authorization using the OpenStack Identity service SQL database, while
providing user authentication through the LDAP directory.
.. important::
For OpenStack Identity service to access LDAP servers, you must
enable the ``authlogin_nsswitch_use_ldap`` boolean value for SELinux
on the Openstack Identity server. To enable and make the option
persistent across reboots::
# setsebool -P authlogin_nsswitch_use_ldap on
Identity configuration is split into two separate back ends; identity
(back end for users and groups), and assignments (back end for domains,
projects, roles, role assignments). To configure Identity, set options
in the :file:`/etc/keystone/keystone.conf` file. See ? for Identity back end
configuration examples and ? for assignment back end configuration examples.
Modify these examples as needed.
.. TODO (DC) Add links to keystone_integrate_identity_backend_ldap.rst and
keystone_integrate_assignment_backend_ldap.rst
.. note::
Multiple back ends are supported. You can integrate the OpenStack
Identity service with a single LDAP server (configure both identity
and assignments to LDAP, or set identity and assignments back end
with SQL or LDAP), or multiple back ends using domain-specific
configuration files.
To define the destination LDAP server
-------------------------------------
Define the destination LDAP server in the :file:`keystone.conf` file:
.. code-block:: ini
:linenos:
[ldap]
url = ldap://localhost
user = dc=Manager,dc=example,dc=org
password = samplepassword
suffix = dc=example,dc=org
use_dumb_member = False
allow_subtree_delete = False
.. note::
Configure ``dumb_member`` if you set ``use_dumb_member`` to true.
.. code-block:: ini
:linenos:
[ldap]
dumb_member = cn=dumb,dc=nonexistent
Additional LDAP integration settings
------------------------------------
Set these options in the :file:`/etc/keystone/keystone.conf` file for a
single LDAP server, or :file:`/etc/keystone/domains/keystone.DOMAIN_NAME.conf`
files for multiple back ends.
**Query option**
Use ``query_scope`` to control the scope level of data presented
(search only the first level or search an entire sub-tree) through LDAP.
Use ``page_size`` to control the maximum results per page. A value of zero
disables paging.
Use ``alias_dereferencing`` to control the LDAP dereferencing option for
queries.
Use ``chase_referrals`` to override the system's default referral chasing
behavior for queries.
.. code-block:: ini
:linenos:
[ldap]
query_scope = sub
page_size = 0
alias_dereferencing = default
chase_referrals =
**Debug**
Use ``debug_level`` to set the LDAP debugging level for LDAP calls.
A value of zero means that debugging is not enabled.
.. code-block:: ini
:linenos:
[ldap]
debug_level = 0
.. warning::
This value is a bitmask, consult your LDAP documentation for
possible values.
**Connection pooling**
Use ``use_pool`` to enable LDAP connection pooling. Configure
connection pool size, maximum retry, reconnect trials, timeout (-1
indicates indefinite wait) and lifetime in seconds.
.. code-block:: ini
:linenos:
[ldap]
use_pool = true
pool_size = 10
pool_retry_max = 3
pool_retry_delay = 0.1
pool_connection_timeout = -1
pool_connection_lifetime = 600
**Connection pooling for end user authentication**
Use ``use_auth_pool`` to enable LDAP connection pooling for end user
authentication. Configure connection pool size and lifetime in
seconds.
.. code-block:: ini
:linenos:
[ldap]
use_auth_pool = false
auth_pool_size = 100
auth_pool_connection_lifetime = 60
When you have finished configuration, restart the OpenStack Identity
service::
# service keystone restart
.. warning::
During service restart, authentication and authorization are
unavailable.
.. include:: keystone_integrate_identity_backend_ldap.rst
.. include:: keystone_integrate_assignment_backend_ldap.rst
.. include:: keystone_secure_identity_to_ldap_backend.rst
.. toctree::
:hidden:
keystone_integrate_identity_backend_ldap.rst
keystone_integrate_assignment_backend_ldap.rst
keystone_secure_identity_to_ldap_backend.rst

71
doc/admin-guide-cloud-rst/source/keystone_secure_identity_to_ldap_backend.rst Normal file
View File

@@ -0,0 +1,71 @@
Secure the OpenStack Identity service connection to an LDAP back end
--------------------------------------------------------------------
The Identity service supports the use of TLS to encrypt LDAP traffic.
Before configuring this, you must first verify where your certificate
authority file is located. For more information, see ?.
.. TODO (DC) figure out how to reference
keystone_integrate_identity_with_ldap.rst with orphan tag
Once you verify the location of your certificate authority file:
**Configuring TLS encryption on LDAP traffic**
#. Open the :file:`/etc/keystone/keystone.conf` configuration file.
#. Find the ``[ldap]`` section.
#. In the ``[ldap]`` section, set the ``use_tls`` configuration key to
``True``. Doing so will enable TLS.
#. Configure the Identity service to use your certificate authorities file.
To do so, set the ``tls_cacertfile`` configuration key in the ``ldap``
section to the certificate authorities file's path.
.. note::
You can also set the ``tls_cacertdir`` (also in the ``ldap``
section) to the directory where all certificate authorities files
are kept. If both ``tls_cacertfile`` and ``tls_cacertdir`` are set,
then the latter will be ignored.
#. Specify what client certificate checks to perform on incoming TLS
sessions from the LDAP server. To do so, set the ``tls_req_cert``
configuration key in the ``[ldap]`` section to ``demand``, ``allow``, or
``never``:
- ``demand``
A certificate will always be requested from the LDAP
server. The session will be terminated if no certificate is provided,
or if the certificate provided cannot be verified against the
existing certificate authorities file.
- ``allow``
A certificate will always be requested from the LDAP
server. The session will proceed as normal even if a certificate is
not provided. If a certificate is provided but it cannot be verified
against the existing certificate authorities file, the certificate
will be ignored and the session will proceed as normal.
- ``never``
A certificate will never be requested.
On distributions that include openstack-config, you can configure TLS
encryption on LDAP traffic by running the following commands instead::
# openstack-config --set /etc/keystone/keystone.conf \
ldap use_tls True
# openstack-config --set /etc/keystone/keystone.conf \
ldap tls_cacertfile ``CA_FILE``
# openstack-config --set /etc/keystone/keystone.conf \
ldap tls_req_cert ``CERT_BEHAVIOR``
Where:
- ``CA_FILE`` is the absolute path to the certificate authorities file
that should be used to encrypt LDAP traffic.
- ``CERT_BEHAVIOR`` specifies what client certificate checks to perform
on an incoming TLS session from the LDAP server (``demand``,
``allow``, or ``never``).

69
doc/admin-guide-cloud-rst/source/keystone_token-binding.rst Normal file
View File

@@ -0,0 +1,69 @@
.. :orphan:
Configure Identity service for token binding
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Token binding embeds information from an external authentication
mechanism, such as a Kerberos server or X.509 certificate, inside a
token. By using token binding, a client can enforce the use of a
specified external authentication mechanism with the token. This
additional security mechanism ensures that if a token is stolen, for
example, it is not usable without external authentication.
You configure the authentication types for a token binding in the
:file:`keystone.conf` file:
.. code-block:: ini
:linenos:
[token]
bind = kerberos
or
.. code-block:: ini
:linenos:
[token]
bind = x509
Currently ``kerberos`` and ``x509`` are supported.
To enforce checking of token binding, set the ``enforce_token_bind``
option to one of these modes:
- ``disabled``
Disables token bind checking.
- ``permissive``
Enables bind checking. If a token is bound to an unknown
authentication mechanism, the server ignores it. The default is this
mode.
- ``strict``
Enables bind checking. If a token is bound to an unknown
authentication mechanism, the server rejects it.
- ``required``
Enables bind checking. Requires use of at least authentication
mechanism for tokens.
- ``kerberos``
Enables bind checking. Requires use of kerberos as the authentication
mechanism for tokens:
.. code-block:: ini
:linenos:
[token]
enforce_token_bind = kerberos
- ``x509``
Enables bind checking. Requires use of X.509 as the authentication
mechanism for tokens:
.. code-block:: ini
:linenos:
[token]
enforce_token_bind = x509

57
doc/admin-guide-cloud-rst/source/keystone_use_trusts.rst Normal file
View File

@@ -0,0 +1,57 @@
.. :orphan:
Use trusts
~~~~~~~~~~
OpenStack Identity manages authentication and authorization. A trust is
an OpenStack Identity extension that enables delegation and, optionally,
impersonation through ``keystone``. A trust extension defines a
relationship between:
**Trustor**
The user delegating a limited set of their own rights to another user.
**Trustee**
The user trust is being delegated to, for a limited time.
The trust can eventually allow the trustee to impersonate the trustor.
For security reasons, some safeties are added. For example, if a trustor
loses a given role, any trusts the user issued with that role, and the
related tokens, are automatically revoked.
The delegation parameters are:
**User ID**
The user IDs for the trustor and trustee.
**Privileges**
The delegated privileges are a combination of a tenant ID and a
number of roles that must be a subset of the roles assigned to the
trustor.
If you omit all privileges, nothing is delegated. You cannot
delegate everything.
**Delegation depth**
Defines whether or not the delegation is recursive. If it is
recursive, defines the delegation chain length.
Specify one of the following values:
- ``0``. The delegate cannot delegate these permissions further.
- ``1``. The delegate can delegate the permissions to any set of
delegates but the latter cannot delegate further.
- ``inf``. The delegation is infinitely recursive.
**Endpoints**
A list of endpoints associated with the delegation.
This parameter further restricts the delegation to the specified
endpoints only. If you omit the endpoints, the delegation is
useless. A special value of ``all_endpoints`` allows the trust to be
used by all endpoints associated with the delegated tenant.
**Duration**
(Optional) Comprised of the start time and end time for the trust.