api-ref: Fix indentation

Additional paragraphs of a bullet list should be indented by two spaces
to align with the first paragraph, e.g.

  - A bullet list item

    Additional detail

Rather than:

  - A bullet list item

     Additional detail

The latter results in the additional paragraphs being rendered as block
quotes.

Change-Id: I18cd39e65fd8d43691c940a6e849765755c46c2e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This commit is contained in:
Stephen Finucane 2024-02-27 13:13:01 +00:00
parent 7dc175a41f
commit 802cc846aa
1 changed files with 85 additions and 85 deletions

View File

@ -155,101 +155,101 @@ Required attributes:
- ``local`` (list of objects)
References a local Identity API resource, such as a ``group`` or ``user`` to
which the remote attributes will be mapped.
References a local Identity API resource, such as a ``group`` or ``user`` to
which the remote attributes will be mapped.
Each object has one of two structures, as follows.
Each object has one of two structures, as follows.
To map a remote attribute value directly to a local attribute, identify the
local resource type and attribute:
To map a remote attribute value directly to a local attribute, identify the
local resource type and attribute:
::
::
[
{
"local": [
{
"user": {
"name": "{0}"
}
}
],
}
]
If the ``user`` attribute is missing when processing an assertion, server
tries to directly map ``REMOTE_USER`` environment variable. If this variable
is also unavailable the server returns an HTTP ``401 Unauthorized`` error.
If the ``user`` has the attribute ``type`` set to ``local`` as well as a
domain specified, the user is treated as existing in the local keystone
backend, and the server will attempt to fetch user details (id, name, roles,
groups) from the identity backend.
If, however, the user does not exist in the backend, the server will
respond with an appropriate HTTP error code.
If the ``type`` attribute is not set to ``local`` in the local rule and no
domain is specified, the user is deemed ephemeral and becomes a member of
the identity provider's domain.
An example of user object mapping to an existing local user:
::
[
{
"local": [
{
"user": {
"name": "username",
"type": "local",
"domain": {
"name": "domain_name"
}
}
}
],
}
]
For attribute type and value mapping, identify the local resource type,
attribute, and value:
::
[
{
"local": [
{
"group": {
"id": "89678b"
}
}
],
[
{
"local": [
{
"user": {
"name": "{0}"
}
}
],
}
]
This assigns authorization attributes, by way of role assignments on the
specified group, to ephemeral users. The users are not added to the group,
but for the duration of the token they will receive the same authorization
as if they were.
If the ``user`` attribute is missing when processing an assertion, server
tries to directly map ``REMOTE_USER`` environment variable. If this variable
is also unavailable the server returns an HTTP ``401 Unauthorized`` error.
::
If the ``user`` has the attribute ``type`` set to ``local`` as well as a
domain specified, the user is treated as existing in the local keystone
backend, and the server will attempt to fetch user details (id, name, roles,
groups) from the identity backend.
[
{
"local": [
{
"group_ids": "{0}"
}
],
}
]
If, however, the user does not exist in the backend, the server will
respond with an appropriate HTTP error code.
It is also possible to map multiple groups by providing a list of group ids.
Those group ids can also be white/blacklisted.
If the ``type`` attribute is not set to ``local`` in the local rule and no
domain is specified, the user is deemed ephemeral and becomes a member of
the identity provider's domain.
An example of user object mapping to an existing local user:
::
[
{
"local": [
{
"user": {
"name": "username",
"type": "local",
"domain": {
"name": "domain_name"
}
}
}
],
}
]
For attribute type and value mapping, identify the local resource type,
attribute, and value:
::
[
{
"local": [
{
"group": {
"id": "89678b"
}
}
],
}
]
This assigns authorization attributes, by way of role assignments on the
specified group, to ephemeral users. The users are not added to the group,
but for the duration of the token they will receive the same authorization
as if they were.
::
[
{
"local": [
{
"group_ids": "{0}"
}
],
}
]
It is also possible to map multiple groups by providing a list of group ids.
Those group ids can also be white/blacklisted.
- ``remote`` (list of objects)