Merge "api-ref: Fix indentation"
This commit is contained in:
Zuul
Gerrit Code Review
commit
ac65d1416d
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue