Support for Keycloak SAML Client creation

[ericwyles]

Updates to uds-core to support creation of saml clients in Keycloak, in addition to the existing support for OIDC clients.

Describe the solution you'd like

• Allow specifying protocol: saml in the sso spec. The protocol field should be optional and restricted to either openid-connect or saml (default to openid-connect)
• Allow specifying protocl mappers. This is also needed for Keycloak client mappers configuration #305 and there are additional mappers needed for saml.
• Allow specifying attributes for the client-registration request to keycloak. This should be restricted to an allowed list of attributes, currently the only allowed key is saml.client.signature
• In the SSO Secret templating, we need to make available the value of keycloak's SAML x509 signing certificate. That value is available in the xml payload here: http://keycloak-http.keycloak.svc.cluster.local:8080/realms/uds/protocol/saml/descriptor and should be fetched programatically and made available to secret templating.

Describe alternatives you've considered

Considered using OIDC instead but some apps don't support it (sonarqube) and we are going forward with gitlab as well.

Additional context

Below is an example request to the keycloak client-registration endpoint showing everything that is required to configure a saml client for sonarqube, this should illustrate the details listed above.

  {
    "clientId": "sonarqube",
    "name": "sonarqube",
    "redirectUris": [
      "https://sonarqube.uds.dev/oauth2/callback/saml"
    ],
    "webOrigins": [
      "https://sonarqube.uds.dev"
    ],
    "protocol": "saml",
    "attributes": {
      "saml.client.signature": "false"
    },
    "protocolMappers": [
      {
        "name": "Name",
        "protocol": "saml",
        "protocolMapper": "saml-user-property-mapper",
        "consentRequired": false,
        "config": {
          "user.attribute": "Username",
          "attribute.nameformat": "Basic",
          "attribute.name": "name"
        }
      },
      {
        "name": "Email",
        "protocol": "saml",
        "protocolMapper": "saml-user-property-mapper",
        "consentRequired": false,
        "config": {
          "user.attribute": "Email",
          "attribute.nameformat": "Basic",
          "attribute.name": "email"
        }
      },
      {
        "name": "Login",
        "protocol": "saml",
        "protocolMapper": "saml-user-property-mapper",
        "consentRequired": false,
        "config": {
          "user.attribute": "Username",
          "attribute.nameformat": "Basic",
          "attribute.name": "login"
        }
      }
    ],
    "defaultClientScopes": [],
    "optionalClientScopes": []
  }

[ericwyles]

We ended up going a different direction with protocol mappers. Instead of exposing them through the spec here, we built some client scopes that bring mappers with them into the keycloak realm in uds-identity-config. A PR showing this pattern is here: defenseunicorns/uds-identity-config#57

And a client can reference them using the defaultScopes in the spec to get the mappers.