Configure SSO/OAuth integration for API Manager

[InfoSec812]

It would be useful to be able to configure authentication (Authn/Authz) providers from the Operator to fully enable Infrastructure-as-Code. For example, being able to deploy Keycloak and then provision the APIManager to use that KeyCloak instance based on the contents of the CR. Perhaps a new/separate CRD for Auth providers?

[eguzki]

Configuring SSO/OAuth integration within your 3scale Product should be some other CRD than APIManager. As APIManager is responsible for deploying and operating 3scale entire installation, which is multitenant and multi product.

The 3scale Operator offers some featured capabilities to manage the lifecycle of a 3scale Product. Note that these featured capabilities are in TP and lack many features. Besides they may have bugs and issues. One of the lacking features is specifically working with OpenAPI Specification resources. The best (and most standard) representation of a 3scale Product is OAS (currently v3), which supports Oauth2 authentication type, including several flows. Although, it is true that OAS3 does not cover entirely 3scale features. In other words, you cannot configure entirely a 3scale Product using OAS3. There are more configuration settings, like accounts, application plans and applications themselves.

Anyway, as I see, some CRD belonging to the featured capabilities of the 3scale operator should reference somehow a OAS resource and then the operator should configure the 3scale Product accordingly. You should either be able to reference some url serving the OAS resource or reference some secret/ConfigMap holding the OAS resource.

Does it make sense to you?

[InfoSec812]

I like the idea of referencing an OpenAPI spec as the "source of truth" about the API. The only issue I see with that is that there is no way to configure the secrets/credentials/configuration for OAuth2/OpenID in an OpenAPI specification, and it would be a security concern even if there were. Placing that configuration in a CR (perhaps under a new CRD) and referencing that configuration from the OpenAPI spec would definitely make sense.

[eguzki]

Yes, that is the very same use case for the 3scale Toolbox CLI. As credentials should not be provided in the OAS, they are taken from the command line as a command parameter.

The analogy for the operator would be: some CR referencing both the OAS spec and the credentials secret. The operator would gather all the information and configure 3scale accordingly.

[InfoSec812]

The toolbox CLI is not really "declarative" though and it more difficult to define in Infrastructure-as-Code. For example, in Ansible, leveraging the CLI would require waiting for API to be available in order to be able to execute the changes and those changes would not be "idempotent". Re-running the same playbook would potentially end up with the same resource being provisioned multiple times.

[eguzki]

The toolbox CLI is designed to be idempotent 3scale/3scale_toolbox#81

Re-running the same playbook would not end up having the same resource being provisioned multiple times.