This spec proposes to expand the endpoint filters feature to service providers.
As of today, each authenticated user will get a service catalog as well as list of trusted service providers within token response. This may pose performance, security usability and last but not least, legal risks. A client scoping his token to a project or domain should be given a list of service providers to whom he can utilize (given his current scope). Getting a full list of cloud-wide trusted service providers will be very inefficient in big cloud deployments, as huge lists of services providers will be returned to all the users. Public cloud providers should also limit service providers in order not to reveal all partnered clouds (this could have some legal implications). Lastly, token responses should only include service providers allowed within current project/domain scope.
In order to scope a service provider to domains/projects, we need to expand the endpoint group filtering feature to support the filtering of service providers. Endpoint filtering should allow for filtering service providers per scoped projects. This limitation comes from the fact that endpoint filtering is available for projects only. Effectively all service providers in the token response should be filtered by configured filters. The change would allow for:
Additionally a configuration option would be added list_all_service_providers with valid options set to True or False. If the option would be True (and this would be default value) keystone would return all service providers in the token response. This would also make service providers filtering disabled. If the option would be False, it would list service providers that were filtered by a service providers filtering. It’s also wise to expect, that after some sane deprecation time list_all_service_providers would become False as a default value.
Propose completely new API, independent from OS-EP-FILTER API being alternative for filtering service providers. The advantage of it would be the ability to add more suitable options from the first iteration of this effort. Additional filtering capabilities would be: * associating a project with service provider(s) * associating all projects within a domain with service provider(s)
None, the service_providers_group model should be able to handle service_providers as exemplified below:
{
"service_providers_group": {
"description": "Example Service Provider Endpoint Group",
"name": "SP-GROUP-1"
"service_providers": [
"sp1",
"sp2",
"sp3"
],
}
}
The rule above should filter the service_provider with ID sp1 and sp2 and sp3.
It would be an extension to existing OS-EP-FILTER API, however new routes would need to be added as we would handle additional use case.