This patch adds support for using mod_auth_openidc instead of shibboleth for
supporting users who have a preference to use oidc for federation. A new
variable called apache_mod is added to keystone_sp allowing the auth library
to be selected. If left undefined shibboleth auth module will continue to be
installed by default maintaining backward compatibility.
This patch does not support simultaneous use of shibboleth and mod_auth_openidc
primarily because shib2 depends on libcurl3 but mod_auth_openidc depends on
libcurl4 which cannot coexist on Ubuntu. This can be resolved when there is a
shib3 package available in a future release of Ubuntu.
Change-Id: I80031f7d3f0fcc2029cd6861dcb6687e8a9f0a2e
If you don't want to generate shibboleth SP key-pair on first playbook run
You can provide sp-cert.pem and sp-key.pem in /etc/openstack_deploy/keystone/
Change-Id: I6fb099cee10ef76f2cd6d20a03ffe53f45a1f85d
Signed-off-by: Kourosh Vivan <kourosh.vivan@osones.com>
The current rolling upgrade implementation
relies on the role to orchestrate the rolling
upgrade. When the role is executed using
playbook serialisation, the db sync contract
is executed before all hosts are upgraded,
potentially resulting in data corruption.
This patch returns the role to the simpler,
best practice model of expecting that the role
is applied to a single host and that the
playbook handles orchestration. This method
can be used with any form of serialisation.
Depends-On: Ie90cdcbf9e73082a2074c8832b7490d188e178af
Change-Id: I5650f16b9a115bd392012b743788057a94d09226
The policy.json file is currently read continually by the
services and is not only read on service start. We therefore
cannot template directly to the file read by the service
(if the service is already running) because the new policies
may not be valid until the service restarts. This is
particularly important during a major upgrade. We therefore
only put the policy file in place after the service restart.
This patch also tidies up the handlers and some of the install
tasks to simplify them and reduce the tasks/code a little.
Change-Id: Ie913e5eb75f3601107b53bab7bda4a02ab1c1024
The keystone role needed a few updates to deal with modern Ansible.
* The changeset pulls in the needed updates to resolve issues causing
the keystone_sp plugin, which powers federation, to crash.
* The changeset pulls in style changes for keystone cert sync removing
the need for the role to leverage the now deprecated memcached key
module.
Closes-Bug: 1660626
Change-Id: I29d444c9631a7511123aa6cd521a20a0e7588645
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
This patch implements upgrading keystone with zero downtime as the
default installation process. Handlers have been modified to ensure that
the first keystone node is stopped, facilitates the database migrations,
and that it is started and available before restarting any other keystone
nodes. Migrations also now only occur when there is a change within the
installed keystone venv.
This process is documented at
http://docs.openstack.org/developer/keystone/upgrading.html#upgrading-without-downtime
A new test scenario has been added for testing basic upgradability
between releases.
Implements: blueprint upgrade-testing
Change-Id: I0d3cfcb80b64d005d60f4c8445f991855f844796
This change implements CentOS 7 support within the os_keystone role.
Depends-on: I333fb1887339e8dc9ebf10ff137dda3cff629dc0
Change-Id: Ib339cd0657f7008fa48bf74f8d6ddd4b8add2ea1
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
The numerous tags within the role have been condensed
to two tags: keystone-install and keystone-config
These tags have been chosen as they are namespaced
and cover the two major functions of the role.
Documentation has been updated to inform how each tag
influences the function of the role.
Change-Id: Iea4bff944ce0a35a4b1bc044171472ea44eda323
This patch adds the ability to configure Keystone as a Service
Provider (SP) for a Federated Identity Provider (IdP).
* New variables to configure Keystone as a service provider are now
supported under a root `keystone_sp` variable. Example configurations
can be seen in Keystone's defaults file. This configuration includes
the list of identity providers and trusted dashboards. (At this time
only one identity provider is supported).
* Identity provider configuration includes the remote-to-local user
mapping and the list of remote attributes the SP can obtain from the
IdP.
* Shibboleth is installed and configured in the Keystone containers when
SP configuration is present.
* Horizon is configured for SSO login
DocImpact
UpgradeImpact
Implements: blueprint keystone-federation
Change-Id: I78b3d740434ea4b3ca0bd9f144e4a07026be23c6
Co-Authored-By: Jesse Pretorius <jesse.pretorius@rackspace.co.uk>
Georgina