feat: configurable authentication flows

[UnicornChance]

Description

There are no breaking changes in this PR.

Everything that is now configurable has a default value that is set to the original value. In the future we may add breaking changes to focus on a specific flow, but at this time we will maintain all three auth flows as default.

Back Story

At this time uds-core + identity-config allows for three different authentication flows: X509, Username Password, Social ( Google SSO ). Having three different authentication flows is often not desired for environments, typically only one or two of these flows is desired, i.e. x509 only, or social and x509.

Keycloak, by default, does not have simple configurations for turning off these different flows individually. Specifically Username Password can be a major pain to turn off in an environment, taking several different settings to entirely disable it.

These changes allow for the configuration of realm and theme to control auth flows from bundle environment variables, a related PR is up in uds-core for these changes to work. The bundle variables are put into a secret, which is then loaded into the statefulset for the identity config init container, which runs the sync.sh and adds those environment variables to the theme.properties file, the realm.json ( which configures the realm settings ) grabs the environment variables by itself.

Testing

Configuring the different auth flows as described in the new doc authentication-flows.md and testing that a user can only register / authenticate via that method. There is a few different ways to do this, configure via bundle and redeploy, update bundle overrides and cycle keycloak things.

Make sure you pull in the corresponding uds-core changes / branch so that the keycloak secret values can be mapped into the theme.properties

Explanation of changes

In the theme, I needed to control how the theme would present different pieces, x509 block, username password, social, register button etc. While conditionally rendering the theme does not provide real security it does improve user experience and attempts to guide the user to the desired outcome. Pairing these changes with real security controls was mostly necessary for UX purposes.

Plugin logic, when registering with a x509, the user still needs to go through the register form. Previously the password and password confirm fields were still present on that form, although they weren't required. The x509 plugin logic required that the password and password confirm fields were returned from the form even if they were empty. By conditionally removing those fields it would break the plugin because the password/confirm fields were null rather than empty.

Realm changes, as mentioned previously the theme changes are only a band-aid fix and a motivated person could still potentially set a password in a non username password environment or reset their password or something to that effect. These configurations are meant to be paired with the theme configurations to actually apply the security measures.

Related Issue

Fixes #279 #152

Relates to #280 #148

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps(https://github.com/defenseunicorns/uds-template-capability/blob/main/CONTRIBUTING.md#submitting-a-pull-request) followed

[mjnagel]

Haven't fully deployed yet, but had a few small comments.

[UnicornChance]

introduced a breaking change with the renaming of OTP_ENABLED, will fix and align other envs with that syntax.