aboutsummaryrefslogtreecommitdiffstats
path: root/keystone-moon/doc/source
diff options
context:
space:
mode:
Diffstat (limited to 'keystone-moon/doc/source')
-rw-r--r--keystone-moon/doc/source/apache-httpd.rst17
-rw-r--r--keystone-moon/doc/source/architecture.rst22
-rw-r--r--keystone-moon/doc/source/configure_tokenless_x509.rst328
-rw-r--r--keystone-moon/doc/source/developing_drivers.rst130
-rw-r--r--keystone-moon/doc/source/federation/websso.rst79
-rw-r--r--keystone-moon/doc/source/index.rst2
-rw-r--r--keystone-moon/doc/source/man/keystone-all.rst4
-rw-r--r--keystone-moon/doc/source/man/keystone-manage.rst4
-rw-r--r--keystone-moon/doc/source/mapping_schema.rst2
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
--------------