Add Endpoint Filter Enforcement to Keystonemiddleware

In Keystone, we have the ability to filter endpoints in the service catalog.
However, at run-time we do not enforce that a target service endpoint actually
exists in the service catalog. This means that a user with a valid token can
access any service endpoint.

Of course, additional security layers such as roles based access control will
limit the scope of this insecurity but nevertheless, in a holistic security
environment, offering the ability to provide layered security such as endpoint
enforcement is important. This is particularly true in the case of global
roles such as an administrator of one service in a vanilla OpenStack
installation who by default will have administrator access to all services.

The proposed solution is to add the endpoint constraint enforcement capability
to the existing auth_token middleware. Endpoint constraint enforcement will
be based on a given global rule in the service’s (Oslo) policy file
matching the endpoint IDs passed in the token. The given rule, if
exists, will be matched against the endpoints found request token’s
service catalog. If there’s at least one match, user is allowed to access the
endpoint. Otherwise, an endpoint access denied exception will be thrown. Since
endpoint constraint enforcement is part of token validation logic, an endpoint
access denied exception is the same as InvalidToken exception. Therefore, the
existing logic for handling InvalidToken exception remains unchanged. For
example, if the delay_auth_decision is set to True, request will still be
propagated down the pipeline despite the endpoint validation failure.

An existing Keystone spec called TokenConstraints talks about adding
endpoint enforcement via token constraints. Our proposal focuses on endpoint
enforcement via the service catalog. The advantage with our approach is
that the change is small and restricted to the Keystone middleware layer.

None - global target enforcement will be turned off by default. If enabled then
the service catalog will be processed to establish compliance with the
configuration. No additional calls to keystone will be necessary so
Impact on performance will be negligible.