On Wed, 25 Mar 2020 at 11:08, Krzysztof Klimonda <kklimonda@syntaxhighlighted.com> wrote:
@Mark Thanks, I remember reading that blog post already :). Just to make sure, in the deployment described in the post you federate keystone with keycloak, but without K2K federation in the middle, right?
Correct, as colleen confirmed, its without K2K federation. We use OIDC to link Keycloak with OpenStack. And also use OIDC between Keycloak and the acutal IdP, For context, we are using this pattern, using Keycloak as the proxy: https://aarc-project.eu/architecture/ I see that as hub-and-spoke when you compare it to other approaches here: https://wiki.geant.org/display/eduGAIN/Federation+Architectures I should be clear the requirements for this project ruled out K2K from the start. Rather than being multi-region, our aim was allowing people to login to OpenStack using the regular organisation credentials. (In the UK university context, we made use of the existing Edugain federation.) Howerver, we also needed something that also allowed user applications to also make use of the same AAAI system, in particular to project the users web apps like JuypterHub, OpenOnDemand, etc.
On a related note, in your blog post you show “chained federation” in Keycloak. Does this setup support generating Keystone tokens for API/CLI access? If so, how does the authentication flow look like?
We are using Application Credentials for all API and CLI access (including terraform): https://docs.openstack.org/keystone/train/user/application_credentials.html They are keystone region specific (which I see as a positive feature), but they work well. (Assuming your federation mapping doesn't use groups, and instead directly maps users to projects) I hope that helps, johnthetubaguy