Validate that the service is in the catalog embedded in the token.

So, auth_token will need a way to identify what it's protecting. Simple, single region deployments can probably depend on service_type just fine, but larger deployments may have multiple services of the same type, even in the same region. Service names are (due to a bug) not unique, so they're not an option. At the service level, service_id is the only viable choice, IMO. If you want to go to the endpoint level, endpoint_ids would work, but the current auth_token configuration throughout openstack uses a single auth_token configuration to protect multiple endpoints (public & admin interfaces, for example). This isn't a blocker, it's just a larger impact on docs (AFAICT). It would also be fairly intuitive to protect by URL (again, you need to identify multiple URLs, for the same reasoning). The upside to this option is that deployers don't need to know service & endpoint IDs for config files; the downside is that changes in the deployed URL need to be reflected in an additional place (central catalog plus auth_token config). -Dolph

Also worth noting that this conflicts with the ?nocatalog end-user option entirely, as the catalog has always been intended to provide service discovery, not to convey authorization attributes. -Dolph