Pki Authentication; Local Vs Remote Keystone - HP HPE VAN SDN Controller 2.7 Administrator's Manual

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
a. Checks if the username/password is valid for the requested user and tenant/project
b. If the username/password/tenant combination is valid:
c. The controller caches the token and returns a copy to its client
d. The controller's client uses this token on each API request to the controller
e. Upon each user request, the controller validates this token by:
f. The revocation list is periodically retrieved from the Keystone server and is used to
determine if a token is revoked
g. 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
key in the AuthenticationManager component.
116 Security
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
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