diff options
Diffstat (limited to 'keystone-moon/doc')
| -rw-r--r-- | keystone-moon/doc/source/apache-httpd.rst | 17 | ||||
| -rw-r--r-- | keystone-moon/doc/source/architecture.rst | 22 | ||||
| -rw-r--r-- | keystone-moon/doc/source/configure_tokenless_x509.rst | 328 | ||||
| -rw-r--r-- | keystone-moon/doc/source/developing_drivers.rst | 130 | ||||
| -rw-r--r-- | keystone-moon/doc/source/federation/websso.rst | 79 | ||||
| -rw-r--r-- | keystone-moon/doc/source/index.rst | 2 | ||||
| -rw-r--r-- | keystone-moon/doc/source/man/keystone-all.rst | 4 | ||||
| -rw-r--r-- | keystone-moon/doc/source/man/keystone-manage.rst | 4 | ||||
| -rw-r--r-- | keystone-moon/doc/source/mapping_schema.rst | 2 |
9 files changed, 557 insertions, 31 deletions
diff --git a/keystone-moon/doc/source/apache-httpd.rst b/keystone-moon/doc/source/apache-httpd.rst index 91eb7011..dbebc86e 100644 --- a/keystone-moon/doc/source/apache-httpd.rst +++ b/keystone-moon/doc/source/apache-httpd.rst @@ -32,12 +32,14 @@ Files ----- Copy the ``httpd/wsgi-keystone.conf`` sample configuration file to the -appropriate location for your Apache server:: +appropriate location for your Apache server, on Debian/Ubuntu systems +it is:: - /etc/$APACHE_DIR/conf.d/sites-available/wsgi-keystone.conf + /etc/apache2/sites-available/wsgi-keystone.conf -Where ``$APACHE_DIR`` is ``httpd`` on Fedora-based systems and ``apache2`` on -Debian/Ubuntu systems. +On Red Hat based systems it is:: + + /etc/httpd/conf.d/wsgi-keystone.conf Update the file to match your system configuration. Note the following: @@ -49,10 +51,11 @@ Keystone's primary configuration file (``etc/keystone.conf``) and the PasteDeploy configuration file (``etc/keystone-paste.ini``) must be readable to HTTPD in one of the default locations described in :doc:`configuration`. -Enable the site by creating a symlink from ``sites-enabled`` to the file in -``sites-available``:: +Enable the site by creating a symlink from the file in ``sites-available`` to +``sites-enabled``, for example, on Debian/Ubuntu systems +(not required on Red Hat based systems):: - ln -s /etc/$APACHE_DIR/sites-available/keystone.conf /etc/$APACHE_DIR/sites-enabled/ + ln -s /etc/apache2/sites-available/keystone.conf /etc/apache2/sites-enabled/ Restart Apache to have it start serving keystone. diff --git a/keystone-moon/doc/source/architecture.rst b/keystone-moon/doc/source/architecture.rst index 75b0ceae..c119e2bd 100644 --- a/keystone-moon/doc/source/architecture.rst +++ b/keystone-moon/doc/source/architecture.rst @@ -156,17 +156,19 @@ variety of environments and needs. The backend for each service is defined in the keystone.conf file with the key ``driver`` under a group associated with each service. -A general class under each backend named ``Driver`` exists to provide an +A general class exists under each backend to provide an abstract base class for any implementations, identifying the expected service -implementations. The drivers for the services are: - -* :mod:`keystone.assignment.core.Driver` -* :mod:`keystone.assignment.core.RoleDriver` -* :mod:`keystone.catalog.core.Driver` -* :mod:`keystone.identity.core.Driver` -* :mod:`keystone.policy.core.Driver` -* :mod:`keystone.resource.core.Driver` -* :mod:`keystone.token.core.Driver` +implementations. The classes are named after the keystone release in which +they were introduced. For eg. ``DriverV8`` for keystone release version 8. +The corresponding drivers for the services are: + +* :mod:`keystone.assignment.core.AssignmentDriverV8` +* :mod:`keystone.assignment.core.RoleDriverV8` +* :mod:`keystone.catalog.core.CatalogDriverV8` +* :mod:`keystone.identity.core.IdentityDriverV8` +* :mod:`keystone.policy.core.PolicyDriverV8` +* :mod:`keystone.resource.core.ResourceDriverV8` +* :mod:`keystone.token.core.TokenDriverV8` If you implement a backend driver for one of the Keystone services, you're expected to subclass from these classes. diff --git a/keystone-moon/doc/source/configure_tokenless_x509.rst b/keystone-moon/doc/source/configure_tokenless_x509.rst new file mode 100644 index 00000000..40b9fd20 --- /dev/null +++ b/keystone-moon/doc/source/configure_tokenless_x509.rst @@ -0,0 +1,328 @@ +.. + Licensed under the Apache License, Version 2.0 (the "License"); you may not + use this file except in compliance with the License. You may obtain a copy + of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + License for the specific language governing permissions and limitations + under the License. + +================================================ +Configuring Keystone for Tokenless Authorization +================================================ + +.. NOTE:: + + This feature is experimental and unsupported in Liberty. + +----------- +Definitions +----------- + +* `X.509 Tokenless Authorization`: Provides a means to authorize client + operations within Keystone by using an X.509 SSL client certificate + without having to issue a token. For details, please refer to the specs + `Tokenless Authorization with X.509 Client SSL Certificate`_ + +.. _`Tokenless Authorization with X.509 Client SSL Certificate`: http://specs.openstack.org/openstack/keystone-specs/specs/liberty/keystone-tokenless-authz-with-x509-ssl-client-cert.html + +Prerequisites +------------- + +Keystone must be running in a web container with https enabled; tests have +been done with Apache/2.4.7 running on Ubuntu 14.04 . Please refer to +`running-keystone-in-httpd`_ and `apache-certificate-and-key-installation`_ +as references for this setup. + +.. _`running-keystone-in-httpd`: http://docs.openstack.org/developer/keystone/apache-httpd.html +.. _`apache-certificate-and-key-installation`: https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04 + +-------------------- +Apache Configuration +-------------------- + +To enable X.509 tokenless authorization, SSL has to be enabled and configured +in the Apache virtual host file. The Client authentication attribute +``SSLVerifyClient`` should be set as ``optional`` to allow other token +authentication methods and attribute ``SSLOptions`` needs to set as +``+StdEnvVars`` to allow certificate attributes to be passed. The following +is the sample virtual host file used for the testing. + +.. code-block:: ini + + <VirtualHost *:443> + WSGIScriptAlias / /var/www/cgi-bin/keystone/main + ErrorLog /var/log/apache2/keystone.log + LogLevel debug + CustomLog /var/log/apache2/access.log combined + SSLEngine on + SSLCertificateFile /etc/apache2/ssl/apache.cer + SSLCertificateKeyFile /etc/apache2/ssl/apache.key + SSLCACertificatePath /etc/apache2/capath + SSLOptions +StdEnvVars + SSLVerifyClient optional + </VirtualHost> + +---------------------- +Keystone Configuration +---------------------- + +The following options can be defined in `keystone.conf`: + +* ``trusted_issuer`` - The multi-str list of trusted issuers to further + filter the certificates that are allowed to participate in the X.509 + tokenless authorization. If the option is absent then no certificates + will be allowed. The naming format for the attributes of a Distinguished + Name(DN) must be separated by a comma and contain no spaces; however + spaces are allowed for the value of an attribute, like 'L=San Jose' in + the example below. This configuration option may be repeated for multiple + values. Please look at the sample below. +* ``protocol`` - The protocol name for the X.509 tokenless authorization + along with the option `issuer_attribute` below can look up its + corresponding mapping. It defaults to ``x509``. +* ``issuer_attribute`` - The issuer attribute that is served as an IdP ID for + the X.509 tokenless authorization along with the protocol to look up its + corresponding mapping. It is the environment variable in the WSGI + enviornment that references to the Issuer of the client certificate. It + defaults to ``SSL_CLIENT_I_DN``. + +This is a sample configuration for two `trusted_issuer` and a `protocol` set +to ``x509``. + +.. code-block:: ini + + [tokenless_auth] + trusted_issuer = emailAddress=mary@abc.com,CN=mary,OU=eng,O=abc,L=San Jose,ST=California,C=US + trusted_issuer = emailAddress=john@openstack.com,CN=john,OU=keystone,O=openstack,L=Sunnyvale,ST=California,C=US + protocol = x509 + +------------- +Setup Mapping +------------- + +Like federation, X.509 tokenless authorization also utilizes the mapping +mechanism to formulate an identity. The identity provider must correspond +to the issuer of the X.509 SSL client certificate. The protocol for the +given identity is ``x509`` by default, but can be configurable. + +Create an Identity Provider(IdP) +-------------------------------- + +In order to create an IdP, the issuer DN in the client certificate needs +to be provided. The following sample is what a generic issuer DN looks +like in a certificate. + +.. code-block:: ini + + E=john@openstack.com + CN=john + OU=keystone + O=openstack + L=Sunnyvale + S=California + C=US + +The issuer DN should be constructed as a string that contains no spaces +and have the right order seperated by commas like the example below. +Please be aware that ``emailAddress`` and ``ST`` should be used instead +of ``E`` and ``S`` that are shown in the above example. The following is +the sample Python code used to create the IdP ID. + +.. code-block:: python + + import hashlib + issuer_dn = 'emailAddress=john@openstack.com,CN=john,OU=keystone, + O=openstack,L=Sunnyvale,ST=California,C=US' + hashed_idp = hashlib.sha256(issuer_dn) + idp_id = hashed_idp.hexdigest() + print(idp_id) + +The output of the above Python code will be the IdP ID and the following +sample curl command should be sent to keystone to create an IdP with the +newly generated IdP ID. + +.. code-block:: bash + + curl -k -s -X PUT -H "X-Auth-Token: <TOKEN>" \ + -H "Content-Type: application/json" \ + -d '{"identity_provider": {"description": "Stores keystone IDP identities.","enabled": true}}' \ + https://<HOSTNAME>:<PORT>/v3/OS-FEDERATION/identity_providers/<IdP ID> + +Create a Map +------------ + +A mapping needs to be created to map the ``Subject DN`` in the client +certificate as a user to yield a valid local user if the user's ``type`` +defined as ``local`` in the mapping. For example, the client certificate +has ``Subject DN`` as ``CN=alex,OU=eng,O=nice-network,L=Sunnyvale, +ST=California,C=US``, in the following examples, ``user_name`` will be +mapped to``alex`` and ``domain_name`` will be mapped to ``nice-network``. +And it has user's ``type`` set to ``local``. If user's ``type`` is not +defined, it defaults to ``ephemeral``. + +Please refer to `mod_ssl`_ for the detailed mapping attributes. + +.. _`mod_ssl`: http://httpd.apache.org/docs/current/mod/mod_ssl.html + +.. code-block:: javascript + + { + "mapping": { + "rules": [ + { + "local": [ + { + "user": { + "name": "{0}", + "domain": { + "name": "{1}" + }, + "type": "local" + } + } + ], + "remote": [ + { + "type": "SSL_CLIENT_S_DN_CN" + }, + { + "type": "SSL_CLIENT_S_DN_O" + } + ] + } + ] + } + } + +When user's ``type`` is not defined or set to ``ephemeral``, the mapped user +does not have to be a valid local user but the mapping must yield at least +one valid local group. For example: + +.. code-block:: javascript + + { + "mapping": { + "rules": [ + { + "local": [ + { + "user": { + "name": "{0}", + "type": "ephemeral" + } + }, + { + "group": { + "id": "12345678" + } + } + ], + "remote": [ + { + "type": "SSL_CLIENT_S_DN_CN" + } + ] + } + ] + } + } + +The following sample curl command should be sent to keystone to create a +mapping with the provided mapping ID. The mapping ID is user designed and +it can be any string as opposed to IdP ID. + +.. code-block:: bash + + curl -k -s -H "X-Auth-Token: <TOKEN>" \ + -H "Content-Type: application/json" \ + -d '{"mapping": {"rules": [{"local": [{"user": {"name": "{0}","type": "ephemeral"}},{"group": {"id": "<GROUPID>"}}],"remote": [{"type": "SSL_CLIENT_S_DN_CN"}]}]}}' \ + -X PUT https://<HOSTNAME>:<PORT>/v3/OS-FEDERATION/mappings/<MAPPING ID> + + +Create a Protocol +----------------- + +The name of the protocol will be the one defined in `keystone.conf` as +``protocol`` which defaults to ``x509``. The protocol name is user designed +and it can be any name as opposed to IdP ID. + +A protocol name and an IdP ID will uniquely identify a mapping. + +The following sample curl command should be sent to keystone to create a +protocol with the provided protocol name that is defined in `keystone.conf`. + +.. code-block:: bash + + curl -k -s -H "X-Auth-Token: <TOKEN>" \ + -H "Content-Type: application/json" \ + -d '{"protocol": {"mapping_id": "<MAPPING ID>"}}' \ + -X PUT https://<HOSTNAME>:<PORT>/v3/OS-FEDERATION/identity_providers/<IdP ID>/protocols/<PROTOCOL NAME> + +------------------------------- +Setup ``auth_token`` middleware +------------------------------- + +In order to use ``auth_token`` middleware as the service client for X.509 +tokenless authorization, both configurable options and scope information +will need to be setup. + +Configurable Options +-------------------- + +The following configurable options in ``auth_token`` middleware +should set to the correct values: + +* ``auth_protocol`` - Set to ``https``. +* ``certfile`` - Set to the full path of the certificate file. +* ``keyfile`` - Set to the full path of the private key file. +* ``cafile`` - Set to the full path of the trusted CA certificate file. + +Scope Information +----------------- + +The scope information will be passed from the headers with the following +header attributes to: + +* ``X-Project-Id`` - If specified, its the project scope. +* ``X-Project-Name`` - If specified, its the project scope. +* ``X-Project-Domain-Id`` - If specified, its the domain of project scope. +* ``X-Project-Domain-Name`` - If specified, its the domain of project scope. +* ``X-Domain-Id`` - If specified, its the domain scope. +* ``X-Domain-Name`` - If specified, its the domain scope. + +--------------------- +Test It Out with cURL +--------------------- + +Once the above configurations have been setup, the following curl command can +be used for token validation. + +.. code-block:: bash + + curl -v -k -s -X GET --cert /<PATH>/x509client.crt \ + --key /<PATH>/x509client.key \ + --cacert /<PATH>/ca.crt \ + -H "X-Project-Name: <PROJECT-NAME>" \ + -H "X-Project-Domain-Id: <PROJECT-DOMAIN-ID>" \ + -H "X-Subject-Token: <TOKEN>" \ + https://<HOST>:<PORT>/v3/auth/tokens | python -mjson.tool + +Details of the Options +---------------------- + +* ``--cert`` - The client certificate that will be presented to Keystone. + The ``Issuer`` in the certificate along with the defined ``protocol`` + in `keystone.conf` will uniquely identify the mapping. The ``Subject`` + in the certificate will be mapped to the valid local user from the + identified mapping. +* ``--key`` - The corresponding client private key. +* ``--cacert`` - It can be the Apache server certificate or its issuer + (signer) certificate. +* ``X-Project-Name`` - The project scope needs to be passed in the header. +* ``X-Project-Domain-Id`` - Its the domain of project scope. +* ``X-Subject-Token`` - The token to be validated. + diff --git a/keystone-moon/doc/source/developing_drivers.rst b/keystone-moon/doc/source/developing_drivers.rst new file mode 100644 index 00000000..1e3996de --- /dev/null +++ b/keystone-moon/doc/source/developing_drivers.rst @@ -0,0 +1,130 @@ +.. + Licensed under the Apache License, Version 2.0 (the "License"); you may + not use this file except in compliance with the License. You may obtain + a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + License for the specific language governing permissions and limitations + under the License. + +=========================== +Developing Keystone Drivers +=========================== + +A driver, also known as a backend, is an important architectural +component of Keystone. It is an abstraction around the data access +needed by a particular subsystem. This pluggable implementation is not +only how Keystone implements its own data access, but how you can +implement your own! + +Each major subsystem (that has data access needs) implements the data access +by using drivers. Some examples of Keystone's drivers: + +- :class:`keystone.identity.backends.ldap.Identity` +- :class:`keystone.token.providers.fernet.Provider` +- :class:`keystone.contrib.federation.backends.sql.Federation` + +In/Out of Tree +-------------- + +It's best to start developing your custom driver outside of the Keystone +development process. This means developing it in your own public or private git +repository and not worrying about getting it upstream (for now). + +This is better for you because it gives you more freedom and you are not bound +to the strict OpenStack development rules or schedule. You can iterate faster +and take whatever shortcuts you need to get your product out of the door. + +This is also good for Keystone because it will limit the amount of drivers +that must be maintained by the team. If the team had to maintain a +driver for each NoSQL DB that deployers want to use in production there +would be less time to make Keystone itself better. Not to mention that +the team would have to start gaining expertise in potentially dozens of +new technologies. + +As you'll see below there is no penalty for open sourcing your driver, +on GitHub for example, or even keeping your implementation private. We +use `Setuptools entry points`_ to load your driver from anywhere in the +Python path. + +.. _Setuptools entry points: no good resource? + +How To Make a Driver +-------------------- + +The TLDR; steps (and too long didn't write yet): + +1. Determine which subsystem you would like write a driver for +2. Subclass the most current version of the driver interface +3. Implement each of the abstract methods for that driver + + a. We are currently not documenting the exact input/outputs of the + driver methods. The best approach right now is to use an existing + driver as an example of what data your driver will receive and + what data your driver will be required to return. + b. There is a plan in place to document these APIs in more detail. + +4. Register your new driver as an entry point +5. Configure your new driver in ``keystone.conf`` +6. Sit back and enjoy! + +Driver Versioning +----------------- + +In the past the driver class was named ``Driver`` and changes would +sometimes be devastating to developers that depend on our driver +contracts. To help alleviate some of the issues we are now creating +version driver classes, e.g. ``DriverV8``. + +We'll be supporting the current driver version for at least one version back. +This gives developers a full cycle to update their drivers. Some cases, such +as critical security flaws, may require a change to be introduced that breaks +compatibility. These special cases will be communicated as widely as possible +via the typical OpenStack communication channels. + +As new driver interface versions are added old ones will be moved to a +"deprecated" state and will output deprecation messages when used. When a +driver version moves from "deprecated" to "unsupported" it will be +removed from the keystone source tree. + +Removing Methods +~~~~~~~~~~~~~~~~ + +Newer driver interfaces may remove methods that are currently required. +Methods are removed when they are no longer required or invoked by Keystone. +There is no reason why methods removed from the Keystone interface need to be +removed from custom drivers. + +Adding Methods +-------------- + +The most common API changes will be adding method to support new +features. We'll do our best to add methods in a way that is backward +compatible. The new version of the driver will define the new method as +an ``abc.abstractmethod`` that must be implemented by driver +implementations. When possible we'll also go back to our supported drivers and +add the method, with a default implementation. + +For example, given a ``thing.DriverV8`` that added a new method +``list_things_by_name()``, we will go back to ``thing.DriverV7`` and +implement that method. This is good because in many cases your driver +will just work, but there are a couple of unfortunate side effects. +First if you have already used that method name you will have to rename +your method and cut a new version. Second is that the default +implementation may cause a performance penalty due to its naive +implementation. + +Updating Methods +~~~~~~~~~~~~~~~~ + +We will try not to update existing methods in ways that will break old +driver implementations. That means that: + +* We will respect existing parameters and not just delete them. If they are + to be removed we will respect their behavior and deprecate them in older + versions. +* We will add new parameters as optional with backward compatible defaults. diff --git a/keystone-moon/doc/source/federation/websso.rst b/keystone-moon/doc/source/federation/websso.rst index 4ada0a4c..682449ac 100644 --- a/keystone-moon/doc/source/federation/websso.rst +++ b/keystone-moon/doc/source/federation/websso.rst @@ -35,9 +35,17 @@ prevent man-in-the-middle (MITM) attacks. 2. Update httpd vhost file with websso information. -The `/v3/auth/OS-FEDERATION/websso/<protocol>` route must be protected by the -chosen httpd module. This is performed so the request that originates from -horizon will use the same identity provider that is configured in keystone. +The `/v3/auth/OS-FEDERATION/websso/<protocol>` and +`/v3/auth/OS-FEDERATION/identity_providers/{idp_id}/protocols/{protocol_id}/websso` +routes must be protected by the chosen httpd module. This is performed so the +request that originates from horizon will use the same identity provider that +is configured in keystone. + +.. WARNING:: + By using the IdP specific route, a user will no longer leverage the Remote + ID of a specific Identity Provider, and will be unable to verify that the + Identity Provider is trusted, the mapping will remain as the only means to + controlling authorization. If `mod_shib` is used, then use the following as an example: @@ -52,6 +60,11 @@ If `mod_shib` is used, then use the following as an example: Require valid-user ... </Location> + <Location ~ "/v3/auth/OS-FEDERATION/identity_providers/idp_1/protocols/saml2/websso"> + AuthType shibboleth + Require valid-user + ... + </Location> </VirtualHost> If `mod_auth_openidc` is used, then use the following as an example: @@ -61,6 +74,7 @@ If `mod_auth_openidc` is used, then use the following as an example: <VirtualHost *:5000> OIDCRedirectURI http://localhost:5000/v3/auth/OS-FEDERATION/websso/redirect + OIDCRedirectURI http://localhost:5000/v3/auth/OS-FEDERATION/identity_providers/idp_1/protocol/oidc/websso/redirect ... @@ -69,6 +83,11 @@ If `mod_auth_openidc` is used, then use the following as an example: Require valid-user ... </Location> + <Location ~ "/v3/auth/OS-FEDERATION/identity_providers/idp_1/protocols/oidc/websso"> + AuthType openid-connect + Require valid-user + ... + </Location> </VirtualHost> If `mod_auth_kerb` is used, then use the following as an example: @@ -87,6 +106,14 @@ If `mod_auth_kerb` is used, then use the following as an example: Krb5Keytab /etc/apache2/http.keytab ... </Location> + <Location ~ "/v3/auth/OS-FEDERATION/identity_providers/idp_1/protocols/kerberos/websso"> + AuthType Kerberos + AuthName "Acme Corporation" + KrbMethodNegotiate on + KrbMethodK5Passwd off + Krb5Keytab /etc/apache2/http.keytab + ... + </Location> </VirtualHost> If `mod_auth_mellon` is used, then use the following as an example: @@ -103,6 +130,12 @@ If `mod_auth_mellon` is used, then use the following as an example: Require valid-user ... </Location> + <Location ~ "/v3/auth/OS-FEDERATION/identity_providers/idp_1/protocols/saml2/websso"> + AuthType Mellon + MellonEnable auth + Require valid-user + ... + </Location> </VirtualHost> .. NOTE:: @@ -182,6 +215,9 @@ Horizon Changes Django OpenStack Auth version 1.2.0 or higher is required for these steps. + Identity provider and federation protocol specific webSSO is only available + in Django OpenStack Auth version 2.0.0 or higher. + 1. Set the Identity Service version to 3 Ensure the `OPENSTACK_API_VERSIONS` option in horizon's local_settings.py has @@ -214,20 +250,45 @@ this will provide users with an updated login screen for horizon. 4. (Optional) Create a list of authentication methods with the `WEBSSO_CHOICES` option. -Within horizon's settings.py file, a list of supported authentication methods -can be specified. The entries in the list map to keystone federation protocols, -with the exception of ``credentials`` which is reserved by horizon, and maps to -the user name and password used by keystone's identity backend. +Within horizon's settings.py file, a list of supported authentication methods can be +specified. The list includes Keystone federation protocols such as OpenID Connect and +SAML, and also keys that map to specific identity provider and federation protocol +combinations (as defined in `WEBSSO_IDP_MAPPING`). With the exception of ``credentials`` +which is reserved by horizon, and maps to the user name and password used by keystone's +identity backend. .. code-block:: python WEBSSO_CHOICES = ( ("credentials", _("Keystone Credentials")), ("oidc", _("OpenID Connect")), - ("saml2", _("Security Assertion Markup Language")) + ("saml2", _("Security Assertion Markup Language")), + ("idp_1_oidc", "Acme Corporation - OpenID Connect"), + ("idp_1_saml2", "Acme Corporation - SAML2") ) -5. (Optional) Specify an initial choice with the `WEBSSO_INITIAL_CHOICE` +5. (Optional) Create a dictionary of specific identity provider and federation + protocol combinations. + +A dictionary of specific identity provider and federation protocol combinations. +From the selected authentication mechanism, the value will be looked up as keys +in the dictionary. If a match is found, it will redirect the user to a identity +provider and federation protocol specific WebSSO endpoint in keystone, otherwise +it will use the value as the protocol_id when redirecting to the WebSSO by +protocol endpoint. + +.. code-block:: python + + WEBSSO_IDP_MAPPING = { + "idp_1_oidc": ("idp_1", "oidc"), + "idp_1_saml2": ("idp_1", "saml2") + } + +.. NOTE:: + + The value is expected to be a tuple formatted as: (<idp_id>, <protocol_id>). + +6. (Optional) Specify an initial choice with the `WEBSSO_INITIAL_CHOICE` option. The list set by the `WEBSSO_CHOICES` option will be generated in a drop-down diff --git a/keystone-moon/doc/source/index.rst b/keystone-moon/doc/source/index.rst index c77d7738..511bc89f 100644 --- a/keystone-moon/doc/source/index.rst +++ b/keystone-moon/doc/source/index.rst @@ -54,6 +54,7 @@ Getting Started configure_federation mapping_combinations mapping_schema + configure_tokenless_x509 configuringservices extensions key_terms @@ -74,6 +75,7 @@ Developers Documentation :maxdepth: 1 developing + developing_drivers architecture middlewarearchitecture http-api diff --git a/keystone-moon/doc/source/man/keystone-all.rst b/keystone-moon/doc/source/man/keystone-all.rst index ea958fe0..b9c219b3 100644 --- a/keystone-moon/doc/source/man/keystone-all.rst +++ b/keystone-moon/doc/source/man/keystone-all.rst @@ -7,9 +7,9 @@ Keystone Startup Command ------------------------ :Author: openstack@lists.openstack.org -:Date: 2014-10-16 +:Date: 2015-10-15 :Copyright: OpenStack Foundation -:Version: 2014.2 +:Version: 8.0.0 :Manual section: 1 :Manual group: cloud computing diff --git a/keystone-moon/doc/source/man/keystone-manage.rst b/keystone-moon/doc/source/man/keystone-manage.rst index 21a3ca4a..2ef2d51a 100644 --- a/keystone-moon/doc/source/man/keystone-manage.rst +++ b/keystone-moon/doc/source/man/keystone-manage.rst @@ -7,9 +7,9 @@ Keystone Management Utility --------------------------- :Author: openstack@lists.openstack.org -:Date: 2015-4-7 +:Date: 2015-10-15 :Copyright: OpenStack Foundation -:Version: 2015.1 +:Version: 8.0.0 :Manual section: 1 :Manual group: cloud computing diff --git a/keystone-moon/doc/source/mapping_schema.rst b/keystone-moon/doc/source/mapping_schema.rst index a020178b..036df827 100644 --- a/keystone-moon/doc/source/mapping_schema.rst +++ b/keystone-moon/doc/source/mapping_schema.rst @@ -22,7 +22,7 @@ The schema for mapping is a description of how a mapping should be created. It shows all the requirements and possibilities for a JSON to be used for mapping. Mapping schema is validated with `JSON Schema -<http://http://json-schema.org/documentation.html>`__ +<http://json-schema.org/documentation.html>`__ Mapping Schema -------------- |