Update Keystone code from repository.

Change-Id: Ib3d0a06b10902fcc6d520f58e85aa617bc326d00

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
 --------------