Using TMC SM with ADFS
search cancel

Using TMC SM with ADFS

book

Article ID: 410275

calendar_today

Updated On:

Products

VMware Tanzu Mission Control - SM

Issue/Introduction

Previous versions of Tanzu Mission Control Self-Managed (TMC-SM) had a known compatibility issue when ADFS was configured as an OIDC identity provider. While the initial login would work and grant access to TMC-SM, the user would be logged out after a short period of time, requiring a fresh login.

Starting with TMC-SM 1.4.2.1 and newer releases, this issue will no longer be present after applying the workaround described below.

Environment

Tanzu Mission Control - Self Managed 1.4.2.1

Cause

The reason for the workaround is that ADFS does not correctly implement the OAuth2 refresh token flow used to extend the user’s login session with TMC-SM.

TMC-SM uses Pinniped for user authentication, and a workaround was added to Pinniped v0.41.0, which is now bundled with TMC-SM 1.4.2.1 and newer versions.

Resolution

Workaround

Start by configuring ADFS as an OIDC identity provider and confirm that TMC-SM login works and users have the expected username and groups. You can find your username from the TMC-SM user interface and check group membership by checking whether TMC-SM recognizes you as a member or admin. See idpGroupRoles.member and idpGroupRoles.admin in the TMC-SM values file.

Then confirm the legacy TMC-SM behavior with ADFS by waiting 10 minutes and then observe that TMC-SM will navigate the browser back to ADFS as though you were performing an additional login. If you have trouble observing this behavior, you can inspect browser network activity, or follow something like these steps:

  • Log into TMC-SM, which requires you to log into ADFS.
  • In a separate browser tab, log out of ADFS.
  • Wait 10 minutes.
  • Observe that TMC-SM no longer respects your session and redirects your browser to ADFS to confirm your identity.

Once this behavior has been observed, you can now configure the TMC-SM installation directly with a YTT overlay to apply the necessary configuration. This configuration is not exposed through the TMC-SM values file.

The following commands and configuration assume that TMC-SM was installed in the tmc-local namespace. If another namespace was chosen, please substitute that value.

First, check for any existing configuration overrides by running this command against the cluster where TMC-SM is installed.

$ kubectl get pkgi/tanzu-mission-control -n tmc-local -o yaml

Inspect metadata.annotations for any keys that begin with "ext.packaging.carvel.dev/ytt-paths-from-secret-name". If any such annotations exist, copy the key/value pairs into a text editor.

Also check for any existing secret names with the word overlay in them.

$ kubectl get secrets -n tmc-local | grep overlay

Put the below YAML into a file such as pinniped-adfs-overlay.yaml.

The secret names tmc-package-overlay and pinniped-supervisor-configmap-overlay shown here should be unique to the tmc-local namespace. If you found either secret name in the above annotations, change the secret name in this file to something else.

The last line of this file has a numerical value in it, shown here to be 0. If you found above annotations with numerical values in them, change this number to be the next value in the sequence to ensure that it is unique.

Be sure to update the placeholder <YOUR_ADFS_ISSUER_URL> to the exactly same string shown in the TMC-SM values file with key oidc.issuerURL.

After verifying the above, apply the file to the cluster where TMC-SM is installed (kubectl apply -f pinniped-adfs-overlay.yaml).

# This file is from Broadcom KB410275
---
apiVersion: v1
kind: Secret
metadata:
  name: pinniped-supervisor-configmap-overlay
  namespace: tmc-local
stringData:
  overlay.yml: |
    #@ load("@ytt:yaml", "yaml")
    #@ load("@ytt:overlay", "overlay")
    #@ def pinniped_values(valuesyml):
    #@   yml = yaml.decode(valuesyml)
    #@   yml["oidc"] = {"ignoreUserInfoEndpoint":{"whenIssuerExactlyMatches":["<YOUR_ADFS_ISSUER_URL>"]}}
    #@   return yaml.encode(yml)
    #@ end
    #@overlay/match by=overlay.subset({"kind":"ConfigMap", "metadata": {"name": "pinniped-supervisor"}}),expects=1
    ---
    #@overlay/match expects=1
    data:
      #@overlay/match expects=1
      pinniped.yaml: #@overlay/replace via=lambda left, right: pinniped_values(left)
---
apiVersion: v1
kind: Secret
metadata:
  name: tmc-package-overlay
  namespace: tmc-local
stringData:
  tmc-pkgi-overlay.yml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"apiVersion":"packaging.carvel.dev/v1alpha1", "kind":"PackageInstall", "metadata": {"name": "pinniped"}}),expects="1+"
    ---
    metadata:
      #@overlay/match missing_ok=True
      annotations:
        #@overlay/match missing_ok=True
      ext.packaging.carvel.dev/ytt-paths-from-secret-name.0: pinniped-supervisor-configmap-overlay

After this YAML file has been applied to the cluster, update the package install to be aware of its existence. Be sure to update the annotation key and value if those were changed in the previous step.

$ kubectl patch pkgi tanzu-mission-control -n tmc-local --type='merge' -p '{"metadata": {"annotations": {"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0": "tmc-package-overlay"}}}'

It may take several minutes for the package to reconcile. You can check that this workaround has been applied by looking at the configmap with name pinniped-supervisor.

$ kubectl get configmap/pinniped-supervisor -n tmc-local -o yaml

The response should contain the following:

data:
  oidc:
    ignoreUserInfoEndpoint:
      whenIssuerExactlyMatches:
      - "<YOUR_ADFS_ISSUER_URL>"

Once this configmap is observed to have the expected values, restart the Pinniped Supervisor pods.

$ kubectl rollout restart deployments/pinniped-supervisor -n tmc-local

After the new Pinniped Supervisor pods are available, try logging into TMC-SM in an incognito browser session and then wait 10 minutes. You should observe that you are able to interact with TMC-SM according to your permission level without the need for any additional login attempts.

Later Debugging

If this solution appears to stop working in the future, such as after a TMC-SM configuration change or upgrade, check the package install for the presence of the expected annotations.

$ kubectl get pkgi/tanzu-mission-control -n tmc-local -o yaml

Additional Information

Resources