BB Extension: Design solution for consuming SSO
Design a way for SSO values to be easily created/consumed inside of the extension. With each package having different values for SSO, it may not be possible for "unknown" apps. But, we could create a more unified value set for defining the SSO on the existing apps we have. Our values seem to be inconsistent.
Activity
added to epic &218 (closed)
added kindfeature priority5 teambigbang labels
I think we need to move all of the IdP specific SSO details to the
ssosection so that all packages can use them. I see a lot of IdP endpoint hardcoding throughout the templates, which we don't want our mission apps to do. I think this set of yaml will get us what we need:# -- Global SSO values used for BigBang deployments when sso is enabled, can be overridden by individual packages. sso: # -- Name of the identity provider name: keycloak # -- Hostname of the identity provider host: login.dso.mil # -- Port of the identify provider service port: 443 # -- Identity provider realm realm: baby-yoda # -- URL for the identity provider. Must use {{ tpl .Values.sso.url . }} to generate url: "https://{{ .Values.sso.provider.host }}/auth/realms/{{ .Values.sso.provider.realm }}" saml: # -- SAML authorization relative path authorization: "protocol/saml" # -- SAML metadata relative path metadata: "protocol/saml/descriptor" # -- OIDC endpoints can be retrieved from `{{ .Values.sso.url }}/.well-known/openid-configuration` oidc: # -- OIDC authorization relative path authorization: "protocol/openid-connect/auth" # -- OIDC logout / end session relative path endSession: "protocol/openid-connect/logout" # -- OIDC JSON Web Key Set (JWKS) relative path jwks: "protocol/openid-connect/certs" # -- OIDC token relative path token: "protocol/openid-connect/token" # -- OIDC user information relative path user: "protocol/openid-connect/userinfo" claims: # -- Claim referring to email address of the user email: email # -- Claim referring to the name of the user name: name # -- Claim referring to the first name of the user firstname: given_name # -- Claim referring to the last name of the user lastname: family_name # -- Claim referring to the username of the user user: preferred_username
-
The current authservice template is using the json string for
jwks. We probably don't want to have our users doing this. Instead, we should be able to dynamically retrieve jwks through the endpoint (authservice supports this). Since the jwks shouldn't be changing often, we can set the interval to be large (hourly? daily?). We can support jwks overrides still if the user wants to paste it via values. assigned to @michaelmcleroy
-
List of value changes planned for this issue:
Old New Notes sso.oidc.host [Deprecated] Use sso.url instead sso.oidc.realm [Deprecated] Use sso.url instead sso.jwks sso.oidc.jwks Not needed if sso.oidc.jwksUriis usedsso.jwks_uri sso.oidc.jwksUri sso.client_id addons.authservice.sso.client_id Only authservice uses sso.client_secret addons.authservice.sso.client_secret Only authservice uses sso.token_url sso.url / sso.oidc.token sso.auth_url sso.url / sso.oidc.authorization sso.certificate_authority sso.certificateAuthority.cert CA cert and secretName are grouped sso.secretName sso.certificateAuthority.secretName CA cert and secretName are grouped monitoring.sso.grafana.auth_url sso.url / sso.oidc.authorization monitoring.sso.grafana.token_url sso.url / sso.oidc.token monitoring.sso.grafana.api_url sso.url / sso.oidc.userinfo twistlock.sso.provider_name sso.name twistlock.sso.issuer_uri sso.url twistlock.sso.idp_url sso.url / sso.saml.service twistlock.sso.groups sso.attributes.group twistlock.sso.cert sso.saml.metadata X.509 certificate derived from metadata twistlock.sso.console_url [Deprecated] Pulls from twistlock.values.istio.console.hostsor defaults totwistlock.<domain>)addons.anchore.sso.role_attribute sso.attributes.group addons.argocd.sso.provider_name sso.name addons.gitlab.sso.label sso.name addons.gitlab.sso.issuer_uri sso.url addons.gitlab.sso.end_session_uri sso.url / sso.oidc.endSession addons.gitlab.sso.uid_field sso.attributes.username addons.mattermost.sso.auth_endpoint sso.url / sso.oidc.authorization addons.mattermost.sso.token_endpoint sso.url / sso.oidc.token addons.mattermost.sso.user_api_endpoint sso.url / sso.oidc.userinfo addons.nexus.sso.idp_data.username sso.attributes.username addons.nexus.sso.idp_data.firstName sso.attributes.firstname addons.nexus.sso.idp_data.lastName sso.attributes.lastname addons.nexus.sso.idp_data.email sso.attributes.email addons.nexus.sso.idp_data.groups sso.attributes.group addons.nexus.sso.idp_data.idpMetadata sso.saml.metadata addons.sonarqube.sso.provider_name sso.name addons.sonarqube.sso.certificate sso.saml.metadata X.509 certificate derived from metadata addons.sonarqube.sso.login sso.attributes.user addons.sonarqube.sso.name sso.attributes.name addons.sonarqube.sso.email sso.attributes.email addons.sonarqube.sso.group sso.attributes.group SSO values that are package-specific continue to be available in the package values (e.g.
client_id,client_secret,scope,role_map).