We will list all the tenants in the system; we should expect to see the one we created:

keystone --os-tenant-name firsttenant --os-username admin --os-password h33l0world --os-auth-url http://oscontrollernode:5000/v2.0 tenant-list

Under the hood, the Python client uses the RESTful API. You would use the API if you were trying to call the services directly without using the client. As an example, consider a developer of a company trying to create hooks in the OpenStack system from the company's custom request portal so that end users don't get to see the actual Horizon database, and even the cloud provisioning engine is abstracted from the end user. We will quickly verify that we are able to use Keystone using the RESTful API.

We will use curl in order to make the RESTful call. The URI for tenant is /tenants, so the full URL will be a public URL appended with the API URI, which in our case is http://oscontrollernode:5000/v2.0/tenants. This is using a GET verb, so we will need an authentication token in order to execute the following curl command to get the token:

curl -vv -d '{"auth":{"passwordCredentials":{"username": "admin", "password": "h33l0world"}}}' -H "Content-type: application/json" http://localhost:5000/v2.0/tokens | python -m json.tool

This will give us the token that we can use in the header:

We extract this token and use it in our next call. The tokens are normally valid for a few minutes to hours, depending on the configuration of Keystone.

Tokens are akin to authentication cookies in a lot of ways. If you have come across any kind of a single sign-on (SSO) system for the Web, you may already be aware of how this functions.

In a single sign-on scenario, when you try to access a protected resource, you send a request to the resource, the web page in question checks for a presence of a cookie and whether that cookie is valid. The cookie has information about the user and sometimes authorization as well.

If the cookie is not present or is present but not valid, then the user is sent to a common webpage where the SSO system authenticates them and assigns a cookie. The SSO system then redirects them to the resource and the user is now granted access.

The token system is similar but with some differences, as follows:

This way, the services themselves never get access to the user credentials but only the tokens that are time-bound to expire. This serves two purposes, that of security and of a single sign-on feel.

curl -s 
  -H "X-Auth-Token: 685590d73e81437da6e97a9b6764213b" 
  http://localhost:5000/v2.0/tenants | python -m json.tool

And we then get the tenants configured in the system, as shown in the following screenshot:

We can now use the token until its expiry for the particular user.