The federated-identity guide in the admin section is out of date
relative to the one in the operator section. It is sort of incoherent
and the information within it that is valuable is already present in the
other guide. Delete this guide in favor of just promoting the operator
guide.
Related-bug: #1793374
Change-Id: I8c0190725d0f7297957bbf10fd9d7184e52ff5f3
The mapping example adds mapped users to a group, so it is misleading to
say that it grants them a role directly, which is the purview of
autoprovisioning. This patch clarifies that, and also updates the role
name to be `reader` which is the new default read-only role.
Followup to https://review.openstack.org/605496
Change-Id: I669df0800275c49ed1ec2c3934301313fb7c4dca
Federation protocols in keystone are very confusing due to the way they
have evolved since the original service provider implementation where
the auth plugin was defined in saml2.py. We renamed saml2.py to
mapped.py[1] and now we can effectively support any federation protocol
as long as there is some kind of Apache module that can understand it
and pass certain IdP and user attributes through to keystone. So we
started recommending not using the 'saml2' auth plugin and instead using
the 'mapped' plugin, eventually removing the the notice when we removed
the plugin[2]. Since the name of the federation protocol resource
created in keystone must match one of the [auth]/methods, we also
changed the documentation to start creating the 'mapped' protocol and
use 'mapped' in the Apache settings[3]. This was really the wrong
course. 'mapped' is not a protocol. Using only 'mapped' prevents us from
defining multiple remote_id_attributes for different protocols.
This patch changes references to the 'mapped' protocol and 'mapped'
plugin back to 'saml2' (we never changed the openid ones). While the
saml2 plugin does not itself exist, it is defined as an entrypoint to
the mapped plugin, so it all works out. This doesn't solve the problem
for if we want to define different remote_id_attributes for different
SAML2.0 implementations, but there is a workaround for that[4]. Using
'saml2' as the protocol name is just much more intuitive than 'mapped'.
[1] https://git.openstack.org/cgit/openstack/keystone-specs/tree/specs/keystone/juno/generic-mapping-federation.rst
[2] https://review.openstack.org/#/c/397456/
[3] https://review.openstack.org/#/c/371210/
[4] https://bugs.launchpad.net/keystone/+bug/1724645/comments/1
Change-Id: I23fc3f1f651c12c4e3c1987dc71008e6e97b4ed8
Related-bug: #1724645
With the docs migration and re-arrangement, some docs
have been shifted to new places, however the referenced
links are still old. Some of them give 404 error or
just point to the home page. This patch fixes those URLs.
Change-Id: Ie6b18ab3d4aa346dac8436dd426277fee4f07fcd
Currently some of the config references docs are a part of
general OpenStack-manuals. Migrating those docs to keystone
documentation so that they can be reviewed effectively by
keystone developers too.
Following the specs, the files are added to admin/ and
configuration/ directories.
The files containing congiguration options are added
in a subsequent patch using oslo.config plugin.
Partial-Bug #1694460
Change-Id: I9a85f610e66a10dac54c50b2a54305e979888ee5
Colleen Murphy