Identity API v2.0 and v3 History¶

Specifications¶

As of the Queens release, Keystone solely implements the Identity API v3. Support for Identity API v2.0 has been removed in Queens in favor of the Identity API v3.

Identity API v3 is a superset of all the functionality available in the Identity API v2.0 and several of its extensions, and provides a much more consistent developer experience.

History¶

You’re probably wondering why Keystone does not implement a “v1” API. As a matter of fact, one exists, but it actually predates OpenStack. The v1.x API was an extremely small API documented and implemented by Rackspace for their early public cloud products.

With the advent of OpenStack, Keystone served to provide a superset of the authentication and multi-tenant authorization models already implemented by Rackspace’s public cloud, Nova, and Swift. Thus, Identity API v2.0 was introduced.

Identity API v3 was established to introduce namespacing for users and projects by using “domains” as a higher-level container for more flexible identity management and fixed a security issue in the v2.0 API (bearer tokens appearing in URLs).

How do I migrate from v2.0 to v3?¶

$ curl -i http://identity:35357/
HTTP/1.1 300 Multiple Choices
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 755
Date: Tue, 10 Jun 2014 14:22:26 GMT

{"versions": {"values": [ ... ]}}

{
    "auth": {
        "passwordCredentials": {
            "password": "my-password",
            "username": "my-username"
        },
        "tenantName": "project-x"
    }
}

{
    "auth": {
        "identity": {
            "methods": [
                "password"
            ],
            "password": {
                "user": {
                    "domain": {
                        "id": "default"
                    },
                    "name": "my-username",
                    "password": "my-password"
                }
            }
        },
        "scope": {
            "project": {
                "domain": {
                    "id": "default"
                },
                "name": "project-x"
            }
        }
    }
}

Why do I see deployments with Keystone running on two ports?¶

During development of the v2.0 API, operational functionality was isolated into different applications within the project. One application was dedicated to end-user functionality and its sole purpose was to authenticate and validate user identities. The second application consisted of more features and allowed operators the ability to manage their deployment by adding or deleting users, creating projects, etc. These applications were referred to as the public and admin APIs, respectively. This deployment model was required by the architecture of the v2.0 API. In a way, authorization was limited to the application you had access to.

Once development began on the v3 API, the code paths for both applications were merged into one. Instead of isolating functionality into separate applications, all functionality was consolidated into a single application. Each v3 endpoint or API is protected by policy instead. This makes deployment and management of Keystone’s infrastructure easier for operators to deploy and for users to consume. As a result, Keystone deployments are not required to deploy separate admin and public endpoints, especially now that the v2.0 API implementation has been removed.

HTTP/1.1 Chunked Encoding¶