Learn more about building Cloud Foundations.

Multi-Cloud applications are a core business for us here at meshcloud. Therefore, we also put some effort into the integration of several OpenStack locations using federation. After all, meshcloud is a federation of public clouds.

Recently, we re-assessed the federated authentication with the OpenStack CLI client using v3.12.0 against a Mitaka OpenSource environment. On the identity provider (IdP) side, we use Keycloak's OIDC capabilities.

Password vs. Token Auth

We look at two options for federated authentication at the command line:


Auth Method: User/Password credentials of Identity Provider


  • Static RC file, no refresh of token necessary
  • RC file itself does not provide any access without password


  • Password necessary at CLI
  • Manual Keystone Token Issuing
  • Risk of using password at CLI


Auth Method: OIDC Java Web Token (JWT) issued by Identity Provider


  • Direct bearer usage, no password necessary (=> automation)
  • Keystone token automatically issued


  • Access not secured if RC file is leaked

So, depending on your use case you might prefer the one over the other. In any case, you prepare an appropriate RC file (=a shell script setting the environment variables to configure the openstack cli).



If you want to use the OpenStack command line using your Identity Provider's user/password credentials, create an RC file like this:

# clear unnecessary settings
# set needed settings
export OS_INTERFACE="public"
# insert here Keystone auth url for the specific cloud
export OS_AUTH_URL="https://keystone.example.com:5000/v3"
export OS_IDENTITY_PROVIDER="keycloak-idp"
export OS_PROTOCOL="oidc"
export OS_CLIENT_ID="meshfed-oidc"
# use any value for client secret if we use a public oidc client
export OS_CLIENT_SECRET="ac2aa84b7685-5ffb-9f1d"
export OS_DISCOVERY_ENDPOINT="https://idp.example.org/auth/realms/meshfed/.well-known/openid-configuration"
export OS_AUTH_TYPE="v3oidcpassword"
# insert here the user name to authenticate
export OS_USERNAME="username"
# this is the local openstack project id
export OS_PROJECT_ID="27a7e59d391d55c6cf4ead12227da57e"
# set password by querying user
export OS_PASSWORD=""
echo "Please enter your Meshcloud Password: "

You need the OS_AUTH_URL refers to the Keystone auth endpoint of the cloud you want to access. OS_IDENTITY_PROVIDER is the label you created with openstack identity provider create when creating the identity provider within OpenStack. OS_CLIENT_ID is the name of the OIDC client configured at the IdP. Now it is important that you set OS_CLIENT_SECRET even if you have not a confidential client configured at the IdP because the OpenStack cli expects it to be present. If you use a "public" OIDC client configuration, just put in a dummy value. OS_DISCOVERY_ENDPOINT sets the metadata endpoint for the IdP server. It saves you to set a lot of other config options (it's already more than enough, isn't it?).

Of course, we set OS_AUTH_TYPE to v3oidcpassword. The username of your IdP account goes to OS_USERNAME and OS_PROJECT_ID needs the local project id of your OpenStack project you want to access. See below if you do not know the project id. The remainder of the script is to ask you for your password on the command line, but you can also set OS_PASSWORD directly.

Command line usage

Now get to your prompt and source the RC file:

➜ source v3oidcpassword.sh
Please enter your OpenStack Password:

After you entered your password, you need to issue a Keystone token and you can start issuing commands:

➜ cli-test openstack token issue
| Field      | Value                            |
| expires    | 2017-08-23T13:37:33+0000         |
| id         | d6d222ccfba24bfa9c85d5baa039f110 |
| project_id | 5edf2f36ac334618a614731a146a60ec |
| user_id    | 7ca9d31f46da4e52b44ac263745e4a77 |
(openstack) router create test
(openstack) router list
| ID           | Name | Status | State | Distributed | HA    | Project                          |
| d1907a5b-... | test | ACTIVE | UP    | False       | False | 5edf2f36ac334618a614731a146a60ec |

If you would like to see the projects you have access to, e.g. to get the right project id for the RC file, issue:

openstack federation project list

And you will see a list of projects you can access with your federated account. Pretty cool, huh? 🙂


If you don't want to deal with passwords at the command line, v3oidcaccesstoken is an alternative to authenticate with OpenStack using the JWT issued by the IdP. A JWT is an encoded JSON data set containing identity and authorization information. You can decode them using jwt.io.


export OS_INTERFACE="public"
export OS_AUTH_TYPE="v3oidcaccesstoken"
export OS_AUTH_URL="https://keystone.example.com:5000/v3"
export OS_IDENTITY_PROVIDER="keycloak-idp"
export OS_PROTOCOL="oidc"
export OS_ACCESS_TOKEN="eyJhbGciOiJSUzI1NiIsIn..........9uFum6TWK_69OAbM3RjFbjiDvg"
export OS_PROJECT_ID="27a7e59d391d55c6cf4ead12227da57e"

You see the configuration is much simpler as lots of information is contained in the JWT access token (it usually is a very long string, we just cut it here for display purposes). Sourcing this file enables you to issue a Keystone token (and hence do work in the project) as long as the OIDC JWT is valid.

Command line usage

Source the file, then start working:

➜ source v3oidcaccesstoken.sh
➜ openstack server list
| ID                                   | Name             | Status | Networks                                    | Image                                    | Flavor     |
| 6447040b-cc8c-46f3-91a8-949aa1744981 | flinktest        | ACTIVE | test=,         | ubuntu-xenial-16.04_softwareconfig_0.0.2 | gp1.medium |

You see it is much shorter in application and does not require to set a password.

Using CLI access with meshcloud

To make multi-cloud access easier, meshcloud already prepares the necessary RC files for your project. Just go to the Panel and select the project and location you want to access. Choose "CLI Access" and you find the RC files for download. Source them into your shell and you're ready to go.


The v3oidcpassword and v3oidcaccesstoken are very helpful to use CLI access on federated OpenStack clouds. However, for automated access (e.g. scripts) neither of them is perfect – either you have to store a password or you have only a limited access token. The OIDC standard has a solution called Offline Tokens. Those are refresh tokens (ie. tokens used to re-issue a new access token without credential re-authentication) that never expire. They are intended for automatic procedures who need access to protected resources. Upon access, the bearer requests a fresh (short-living) access token using the Offline Token. The major advantage is that Offline Tokens can be revoked at the IdP site. A revoked Offline Token cannot be used to acquire new access tokens and hence access is disabled. So you still have a central veto when providing decentral access without passwords.

Soon, meshcloud will provide an integrated CLI client that makes accessing multiple clouds and projects more convenient and helps you speed up with your open-source multi-cloud experience. Stay tuned :).


Any questions left? How are you using federated authentication with OpenStack? Let us know. We're looking forward to hear from you.

4 responses to “Federated Authentication with the OpenStack CLI”

  1. Sadok says:

    In Os protocol, i have two possibilities openid and mapped, oidc does not exist.
    When i try mapped, i got Unauthorized. When i try openid i got a syntax error “simplejson.scanner.JSONDecodeError”
    Any help on this point?

    • Jörg Gottschlich says:

      Do you possibly mix up front- and backend configuration? openid and mapped are values which go to keystone.conf methods in the [auth] section.
      Here we look at the command line client and its parameters which worked as described.
      However, as the CLI client is usually under heavy development, the exact configuration can differ between versions. Therefore, I suggest you look closely at the documentation which exactly matches the version you use (and you should update to the most recent CLI, too). For our purposes, we even had to check the source code of the CLI client to collect all necessary information, but I suppose the docs have been improved by now and the interface has stabilized. Hope this helps.

  2. Sadok says:

    Thank you for the post. Actually, i could make federation with CLI working.
    My issue is about using terraform using the federated user, was this tested? i see that terraform attributes are not the same as admin-rc file, any ideas ?

    • Most federation setups are usually centered around interactive user authentication which is not suitable for automation. So automation with federated users is usually not possible and tooling support is poor.
      If you’re managing your OpenStack with meshcloud you can create a Service User in self-service. This is a managed local user account with traditional credentials (username/password) that you can plug into most automation tools like Terraform or your CI/CD server. meshcloud manages the lifecycle of that Service User, i.e. we track who created the user, attach it to the meshProject, can revoke it etc.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.