REST authentication

The HPE VAN SDN Controller relies on token-based authentication to authenticate its REST APIs. All REST APIs except the /auth and /rsdoc APIs require an authentication token embedded in an X-Auth-Token header to be included with each REST request. The /auth API allows you to obtain a token, while the /rsdoc API provides REST API documentation information about the controller’s REST API.


[CAUTION: ]

CAUTION: The HPE VAN SDN Controller REST API documentation is accessible from a web browser through the controller RSdoc API explorer and in PDF format in the Hewlett Packard Enterprise Information Library for SDN. The RSdoc for your controller can also contain REST API documentation added by applications installed on the controller. Although the RSdoc API explorer interacts directly with the controller REST API, RSdoc is not intended as a management or configuration interface. Use caution when using the Try it out! button for POST or PUT methods because this action can result in changes to your current controller environment.


OpenStack Keystone used for user and token management

The SDN Controller uses Openstack Keystone as an identity management for managing users, generating tokens, as well as token validation.

The controller supports Keystone releases supporting the 2.0 REST API from Folsom up to the Juno release. It supports the following token authentication providers:

  • UUID – 32 character string (All Keystone releases)

  • PKI – CMS message containing service catalog, user roles, and metadata (Grizzly and later)

  • PKIZ – ZLIB compressed PKI token (Juno and later)

The controller is configured by default to auto-detect the token provider. It can also be forced to use a specific provider. 

The auto detection logic determines that any token longer than 32 characters is PKI or PKIZ. Distinguishing between PKI and PKIZ is accomplished by detecting the PKIZ prefix which is prepended to PKIZ compressed tokens.

UUID Authentication

The UUID authentication follows this process:

  1. The controller, upon receiving the username/password pair for a user, sends the pair along with a tenant/project to the Keystone Identity Management service.

  2. Keystone upon receiving the username/password pair:

    • Checks if the username/password is valid for the requested user and tenant/project

    • If the username/password/tenant combination is valid:

      • Generates a UUID token

      • Stores the UUID token in its backend

      • Sends a copy of the UUID token back to the controller

  3. The controller caches the token and returns a copy to its client

  4. The controller’s client uses this token on each API request to the controller

  5. Upon each user request, the controller sends this UUID back to Keystone for validation

  6. Keystone returns success or failure status to the controller

  7. On success Keystone grants access to its client to the API call, otherwise it would fail the call with an authorization failure message

This design requires every API request to call in to Keystone for validation. This approach does not scale well as the number of API calls increases. The PKI authentication mechanism addresses this issue by using a private/public key pair to produce a CMS message which can be verified by an endpoint without checking with Keystone for every API request.

PKI Authentication

The PKI authentication provider was introduced in the Grizzly release of Keystone. To use PKI tokens, keys and certificates need to be generated. In Grizzly, this is done by using the keystone-manage pki_setup command. Keystone becomes a (CA) by signing user tokens.

The authentication process is as follows:

  1. At startup the controller

    • Starts a task which periodically downloads the CA and signing certificates from the Keystone server (configurable using the PKICertsDownloadHour item)

    • Starts a task which periodically downloads the token revocation list from the Keystone server (configurable using the RevListPollPeriod item)

  2. The controller upon receiving the username/password pair for a user, sends the pair along with a tenant/project to the Keystone Identity Management service

  3. Keystone upon receiving the username/password pair

    1. Checks if the username/password is valid for the requested user and tenant/project

    2. If the username/password/tenant combination is valid:

      • Builds a JSON message using:

        • Service catalog details

        • User role

        • Metadata

      • Produces a CMS message signing it using the private key

      • Strips the header, footer and produces a URL safe base64 encoded token

      • Returns the token to the controller

    3. The controller caches the token and returns a copy to its client

    4. The controller’s client uses this token on each API request to the controller

    5. Upon each user request, the controller validates this token by:

      • Checking if the token is in its cache if it generated the token

      • Checking if the token is valid using signature verification with the signing certificate if the token is not in its cache and not on the revocation

      • If the received token is compressed the controller decompresses it before checking the signature

    6. The revocation list is periodically retrieved from the keystone server and is used to determine if a token is revoked

    7. The periodic certificate download results in the CA and signing certificates to be updated daily

Local vs Remote Keystone

By default the keystone server is assumed to be installed on the same machine (localhost) as the controller.A remote Keystone server can be specified using the ServerVIP configuration item in the AuthenticationManager configuration set.

Keystone controller configuration

The following Keystone controller configuration is set in the controller UI Configurations screen under the com.hp.sdn/adm/auth.impl.AuthenticationManager component. The keys are described as follows:

AdminToken – Keystone admin token.

ConnPoolEvictPeriod – Keystone idle connection clean-up cycle in milliseconds. Minimum is 100.

ConnPoolMaxActive – Keystone maximum active connections. Minimum is 1.

ConnPoolMaxIdle – Keystone maximum idle connections. Minimum is 1.

ConnPoolMinIdleTime – Keystone minimum idle connection time in milliseconds. Minimum is 1000.

ConnSSLClientAuth – Keystone mutual authentication using TLS.

ConnTimeout – Keystone connection timeout in milliseconds. Minimum is 0.

Keystore – Keystone keystore location.

KeystorePass – Keystone keystore password.

MaxCachedTokens – Maximum number of cached tokens. Minimum is 0.

PKICertsDownloadHour – Hour in a 24 hour day (0-23) when PKI certificates download form the Keystore server occur.

PKICertsPath – Keystone PKI (signing and CA) certificates location.

RevListPollPeriod – Keystone PKI revocation list poll interval in seconds.

ServerPort – Keystone server port.

ServerVIP – Keystone server virtual IP.

ServiceRole – Role for shared secret.

ServiceTenant – Tenant (project) for shared secret.

ServiceToken – Shared secret for internal requests.

ServiceTokenTimeout – Timeout for shared secret, 0 for never. Minimum is 1.

ServiceUser – User for shared secret.

Tenant – Keystone tenant (only a single tenant is supported).

TokenProvider – Keystone token provider (Auto-Detect | PKI | PKIZ | UUID)

Truststore – Keystone truststore location.

TruststorePass – Keystone truststore password.

UserRole – Keystone user role (only a single role is supported. Only a user having this role is allowed access to the controller.

For information on Keystone, see the OpenStack Keystone documentation at http://docs.openstack.org/developer/keystone/.

Security

Since tokens for either providers (UUID, PKI, or PKIZ) are bearer tokens, they should be protected by using mutually authenticated TLS. This can be accomplished by using valid PKI transport configuration as described in Changing the default controller keystore and truststore to use CA signed certificates:

The controller must have:

  • The valid trusted CA signed identity and CA certificates configured in the controller keystore

  • The CA certificate must be configured in the controller truststore

  • The authentication manager ConnSSLClientAuth should be set to true to enforce mutual authentication

Keystone should be configured to:

  • Use valid trusted CA signed identity certificate

  • Configure trusted CA to be used to validate client certificates

  • Require SSL

  • Require the client certificate to be valid

Role-Based Access Control (RBAC)

HPE VAN SDN Controller 2.6 supports limited RBAC (Role Based Access Control). The SDN Controller currently enforces a single role which has access to all controller features. By default, the single role is sdn-admin. The authenticated user must have this role in order to be granted access to the controller. You must ensure that Keystone is configured to grant this role.

The applications installed on the SDN Controller can enforce RBAC to meet their security requirements.

Assigning a user to a role

To assign a user the sdn-admin role and give the user access to the desired SDN Controller:

  1. Create a tenant (the example creates a test tenant):

    -H "X-Auth-Token:ADMIN" -H "Content-Type: application/json" 
    -d '{"tenant": {"enabled": true, "name": "test-tenant", "description": "Test Tenant"}}' 
    http://<controller-ip>:35357/v2.0/tenants
    
  2. List tenants:

    curl -H "X-Auth-Token:ADMIN" http://<controller-ip>:35357/v2.0/tenants
    
  3. Create a user:

    curl -H "X-Auth-Token:ADMIN" -H "Content-Type: application/json" 
    -d '{"user": {"email": "tester@test.rose.hp.com", "password": "somepass", "enabled": true, 
    "name": "test-user", "tenantId": "2c851897a09f483fa452e2de11511f71"}}' 
    http://<controller-ip>:35357/v2.0/users
    
  4. List users:

    curl -H "X-Auth-Token:ADMIN" http://<controller-ip>:35357/v2.0/users
    
  5. Create a role:

    curl -H "X-Auth-Token:ADMIN" -H "Content-Type: application/json" -d '{"role": {"name": "test-role"}}' http://<controller-ip>:35357/v2.0/OS-KSADM/roles
    
  6. List roles:

    curl -H "X-Auth-Token:ADMIN" http://<controller-ip>:35357/v2.0/OS-KSADM/roles
    
  7. Assign a user to a role:

    curl -X PUT -H "X-Auth-Token:ADMIN"; http://<controller-ip>:35357/v2.0/tenants/<tenant-id>/users/<user-id>/roles/OS-KSADM/<role-id>
    
  8. List roles for a user for a given tenant:

    curl -X GET -H "X-Auth-Token:ADMIN" http://<controller-ip>/v2.0/tenants/<tenant-id>/users/<user-id>/roles
    
Example

1. List tenants

root@sdnctl1:/var# curl -H "X-Auth-Token:ADMIN" http://192.168.4.61:35357/v2.0/tenants | python -mjson.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   243  100   243    0     0  38786      0 --:--:-- --:--:-- --:--:-- 40500
{
    "tenants": [
        {
            "description": "",
            "enabled": true,
            "id": "575d62cc28bc403c97409072ba6536d3",
            "name": "sdn"
        },
        {
            "description": "Test Tenant",
            "enabled": true,
            "id": "fb2f0c68d410440baf67ba134733dbdb",
            "name": "test-tenant"
        }
    ],
    "tenants_links": []
}

2. Create a user as part of sdn tenant

root@sdnctl1:/var# curl -H "X-Auth-Token:ADMIN" -H "Content-Type: application/json" 
-d '{"user": {"email":"tester@test.rose.hp.com", "password": "somepass", "enabled": true, 
"name": "test-user", "tenantId":"575d62cc28bc403c97409072ba6536d3"}}' http://192.168.4.61:35357/v2.0/users
{"user": {"username": "test-user", "name": "test-user", "id": "867e7e2e88644e73a4eee25e4b80c303", 
"enabled": true, "email": "tester@test.rose.hp.com", "tenantId": "575d62cc28bc403c97409072ba6536d3"}}
root@sdnctl1:/var# curl -H "X-Auth-Token:ADMIN" http://192.168.4.61:35357/v2.0/users | python -mjson.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   297  100   297    0     0  36232      0 --:--:-- --:--:-- --:--:-- 37125
{
    "users": [
        {
            "enabled": true,
            "id": "4a4a30ce53b743798dd79d98f5ab7daf",
            "name": "sdn",
            "username": "sdn"
        },
        {
            "email": "tester@test.rose.hp.com",
            "enabled": true,
            "id": "867e7e2e88644e73a4eee25e4b80c303",
            "name": "test-user",
            "tenantId": "575d62cc28bc403c97409072ba6536d3",
            "username": "test-user"
        }
    ]
}

3. List roles

root@sdnctl1:/var# curl -H "X-Auth-Token:ADMIN" http://192.168.4.61:35357/v2.0/OS-KSADM/roles | python -mjson.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   342  100   342    0     0  58481      0 --:--:-- --:--:-- --:--:-- 68400
{
    "roles": [
        {
            "description": "Default role for project membership",
            "enabled": "True",
            "id": "9fe2ff9ee4384b1894a90878d3e92bab",
            "name": "_member_"
        },
        {
            "id": "1719c0d3b647488da8ca7ff6a1d0288b",
            "name": "sdn-user"
        },
        {
            "id": "c105e3dc4a484f5582563e28f7483edc",
            "name": "sdn-admin"
        },
        {
            "id": "67eb2907e94d43f7b3e2518485e20bbc",
            "name": "test-role"
        }
    ]
}

4. Assign user to sdn-admin role for the sdn tenant

root@sdnctl1:/var# curl -X PUT -H "X-Auth-Token:ADMIN" 
http://192.168.4.61:35357/v2.0/tenants/575d62cc28bc403c97409072ba6536d3/users/
867e7e2e88644e73a4eee25e4b80c303/roles/OS-KSADM/c105e3dc4a484f5582563e28f7483edc
{"role": {"id": "c105e3dc4a484f5582563e28f7483edc", "name": "sdn-admin"}}

5. Verify which roles this user has for the sdn tenant

root@sdnctl1:/var# curl -X GET -H "X-Auth-Token:ADMIN" http://192.168.4.61:35357/v2.0/tenants/575d62cc28bc403c97409072ba6536d3/users/867e7e2e88644e73a4eee25e4b80c303/roles | python -mjson.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   213  100   213    0     0  11715      0 --:--:-- --:--:-- --:--:-- 12529
{
    "roles": [
        {
            "description": "Default role for project membership",
            "enabled": "True",
            "id": "9fe2ff9ee4384b1894a90878d3e92bab",
            "name": "_member_"
        },
        {
            "id": "c105e3dc4a484f5582563e28f7483edc",
            "name": "sdn-admin"
        }
    ]
}

API access requires authentication

To authenticate, one needs to present username and password to the /auth API as below (using curl as an example):

curl -sk -H 'Content-Type:application/json' -d '{"login":{"user":"sdn","password":"skyline","domain":"sdn"}}'
https://<controller-ip>:8443/sdn/v2.0/auth

[CAUTION: ]

CAUTION: Credential information (user name, password, domain, and authentication tokens) used in curl commands might be saved in the command history. For security reasons, Hewlett Packard Enterprise recommends that you disable command history prior to executing commands containing credential information.

The above call returns this example JSON data structure that includes the authentication token, which, by default, expires in 24 hours:


{
   "record": {
       "domainId": "62e312edff47413fad7e1d7fa6ac7bc7",
       "domainName": "sdn",
       "expiration": 1377917359000,
       "expirationDate": "2013-08-30 19-49-19 -0700",
       "token": "54a6f80a9ae243db89bfa05de4ced51d",
       "userId": "bca3dea8a28b457e99e899ae16b79634",
       "userName": "sdn"
       "roles":["sdn-user","sdn-admin"],
    }
}

[CAUTION: ]

CAUTION: Please guard this token information, as it can be used as an API key to gain access to your controller REST APIs.


To gain access to the REST API, include the token in the X-Auth-Token header as in the following curl example:

curl -sk -H "X-Auth-Token:54a6f80a9ae243db89bfa05de4ced51d" https://<controller-ip>:8443/sdn/v2.0/systems

One can continue using the same token for different SDN Controller APIs within the default 24-hour period since token creation. If desired, one can change this default 24-hour timeout in the /etc/keystone/keystone.conf file. (See the OpenStack Keystone Administration Guide for more information).

Service and admin tokens

The Service token is used for internal communication between controllers and is not exposed to the user. The Admin token is used for communication between controller and the Keystone server and is not exposed to the user.

The values for these tokens can be seen in the controller UI in the Configurations screen under the com.hp.sdn/adm/auth.impl.AuthenticationManager component. All controllers in a team must have the same Service token to communicate successfully. For the Admin token, both the controller token value and the Openstack Keystone admin_token in the directory /etc/keystone/keystone.conf must match for successful authentication.