•
Controller hybrid mode must be enabled (set to
true
).
•
The value of the
com.hp.sdn.cms.impl.ClientMapperServiceProvider
controller
configurable component key
clearpass.integration.enabled
must be
true
.
Requirements for the REST API request when using certificate-based
authentication
•
Certificate-based authentication can only be used for
cms/client/event
POST requests.
•
The request must not include an X-Auth-Token in the request header.
•
The URI for the request must use port 8445. For example:
POST https://
CONTROLLER_IP
:8445/sdn/v2.0/cms/client/event
where
CONTROLLER_IP
is the IP address of the controller
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
REST authentication
115