In-depth understanding of Keystone Certification

Recently in the Keystone, learn a few Keystone authentication methods: UUID, PKI.

UUID Certification Process

1. The user enters the user name password and sends it to Keystone. The user password entered at Horizon Login or the username and password environment variable of source in CLI.

2. Keystone validates the user name password and generates a token (UUID) that is sent to the client.

3. Client Cache UUID Token

4. The client sends a specific execution request (Nova boot) and UUID to Keystone.

5. Keystone the token from the HTTP request and checks to see if token is valid

6. Token is valid, processes the request, and returns the client request result

7. Token expires, rejecting the client request and returning 401.

PKI Certification

Generate the private key and self-signed certificate with Keystone-manage Pki_setup.

With the PKI (including Pkiz) authentication method, Keystone is equivalent to an authoritative authentication center, he uses his own and the private key certificate to sign the token of the user. Each API endpoint in the OpenStack service has a copy of the Keystone-issued certificate, the invalidation list, and the root certificate. API does not have to go directly to Keystone authentication token is legal, only need to according to the Keystone Certificate and the expiration list can determine whether token is legitimate. However, there will always be a need to request Keystone to get the invalid list of operations, inevitably.

Both formats have pros and cons, the biggest difference is that the UUID must be keystone each time to be certified, and the PKI is self-contained, the service can itself according to the standard algorithm to check the signature, the benefit is to improve the validation efficiency, Keystone does not become the bottleneck for the entire openstack. However, PKI token also poses a problem, because PKI tokens contain a lot of metadata and information such as catalog, it will be very large, not only to bring network overhead, and may exceed some server restrictions, throw an exception

The PKI certification process is similar to the UUID, and can be compared to the top two graphs. Only the bottom few are different.

1) token in CMS format

Cmstoken contains three parts: service catalog,user role and metadata. Examples are as follows:

{"
   access": {
       "metadata": {
           .... metadata goes here ...
       },
       "Servicecatalog": [
           .... Endpoints Goes here ...
       ],
       "token": {
           "expires": "2013-05-26t08:52:53z",
           "id": "placeholder",
           "issued_ At ":" 2013-05-25t18:59:33.841811 ",
           " tenant ": {
               " description ": null,
               " enabled ": True,
               " id ":" 925c23eafe1b4763933e08a4c4143f08 ",
               " name ":" User "
           }
       ,
       " user ": {
           .... UserData goes here ....
       }
   }
}

2) Token verification

Token verification consists of three aspects: token signature, whether token is invalid, and token is already in the revocation list.

With OpenSSL cms-verify-certfile/tmp/keystone-signing-nova/signing_cert.pem-cafile/tmp/keystone-signing-nova/ Cacert.pem-inform pem-nosmimecap-nodetach-nocerts-noattr < Cms_token command verifies token signature.

Determine if token is invalid according to expiration date

Check to Keystone if token is already in the revocation list.

OpenStack Related Technical Exchange please Dabigatran: 314889201