Simplify installing and referencing authentication services

Overview

With the changes proposed in #2288 , we should have a way to easily deploy and install the standard authentication service for EnMasse service admins. A controller managing the provisioning and installation of the standard authentication service would simplify the work of an EnMasse service admin.

In addition, a service admin might want to be able to control which authentication services are available to a tenant. And the tenant should not have to care about authentication service details such as location of CA cert secrets.

Requirements

• As a service admin, I want to install the standard authentication service independently of the ‘core’ EnMasse system
• As a service admin, I want to configure the authentication services available to the messaging tenant
• As a messaging tenant, i want to list the available authentication services
• As a messaging tenant, I want to reference an authentication service when creating an address space

Design

Installation of standard authentication service

Design doc: https://github.com/EnMasseProject/enmasse/blob/01255db111ec553a0fdbd575d51c62634f47cf1c/documentation/design/proposals/auth-service-controller.adoc

The existing keycloak-controller logic that creates realms in the standard authentication service will be moved to the address-space-controller. The address-space-controller already deals with configuration related to an address space, and is already checking for realm availability in Keycloak.

The keycloak-controller component will be changed to watch StandardAuthenticationService resources, and create the standard authentication service as specified by the resource. Some of the logic of creating keycloak resources already exists, but will now be created based on the creation of a StandardAuthenticationService instead of by default.

Defining authentication services

Design doc: https://github.com/EnMasseProject/enmasse/blob/01255db111ec553a0fdbd575d51c62634f47cf1c/documentation/design/proposals/auth-service-resource.adoc

Tasklist

• Move existing per-address space keycloak-controller logic into address-space-controller
• Create CRD for the StandardAuthenticationService resource and modify keycloak-controller to create deployment and resources needed for keycloak based on it
• Remove standard-authservice templates, and move keycloak-specific templates to a new keycloak-controller that is included in the default install bundles
• Create CRD for the AuthenticationService and have keycloak-controller create that
• Modify address-space-controller to watch AuthenticationService resources and look for them in the AddressSpace definition.

[lulf]

@rgodfrey, @k-wall,

Now that I’m in the implementation of this, I wonder if it would be better to unify the AuthentiationService and StandardAuthenticationService types. This is to avoid another NoneAuthenticationService type and pollution of the operator UI.

Instead, I’d like to add a type field and per-type properties in the AuthenticationService spec. This will make it easier to manage for the admin I think, and also easier to reconcile the resources. The status field can be used to provide a unified “run-time” view of host, port, certs etc

[lulf]

Fixed in #2415