Open Stack

Hi Chris, responses inline:

> > On Wed, 25 Mar 2020 at 08:49, Krzysztof Klimonda
> > <kklimonda at syntaxhighlighted.com> wrote:
> >> 
> >> Hi Colleen,
> >> 
> >> Interesting - I’ve looked at K2K federation initially, but it didn’t seem to fit my requirements.
> >> 
> >> My understanding is that in this setup we have a global keystone (which I’ve described in my initial post)
> >> and then all regions are federated to that keystone. Is that correct? Would that work with an existing
> >> SSO that we have in place (Keycloak) or does global keystone has to be IdP and not chain to another one?

In the setup I described, there doesn't necessarily need to be a global or authoritative keystone. Rather, each keystone could act as both an IdP and an SP to one another. We usually simplify it in documentation to describe a keystone instance as being one or the other, but in practice there's no need for that restriction. In theory a keystone instance could work as a service provider to a Keycloak IdP while also acting as an IdP for other keystones. 

On Wed, Mar 25, 2020, at 04:00, Krzysztof Klimonda wrote:
[snipped]
> @Colleen I’m trying to visualise your proposed solution, does this 
> diagram make sense: http://paste.openstack.org/show/791120/ ? In K2K 
> federation, how are regions handled? Are they out of the picture, with 
> federated keystone taking their place instead? I assume all keystone 
> catalogs are separate, and users must use specific cloud auth url to 
> authenticate. Authentication can be then delegated to central keystone, 
> but what about another layer of SSO, i.e. Keycloak? 
[snipped]

Your diagram is a hierarchical tree where it doesn't necessarily need to be, it could be a bidirected graph. But having a single known entrypoint into the cluster of clouds as shown in the diagram may also be a good way to structure it.

"Regions" in the OpenStack sense of the word would not really apply because regions are owned by a single keystone instance. This also does indeed mean that the catalogs are separate, so users could only discover other catalogs by knowing the endpoint of one keystone, discovering service providers for that keystone, and then querying for catalogs from the other keystone service providers. The lack of a global or federated catalog for this use case is something that we recognize as a gap.

The other, simpler "federation" approach that has been mentioned in this thread is to omit keystone as an IdP and instead use an external non-OpenStack IdP like Keycloak as your source of identity for all sites. This is conceptually easier but still doesn't solve the problem of having no shared catalog between sites.

Colleen (cmurphy)