You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When logging in at Weave GitOps with Azure AD configured as OIDC provider, then the sub claim which is the recommended way to identify users in Azure AD is also used as the user's name:
Environment
Weave-Gitops Version: 0.29.0
Flux Version: 2.0.1
Kubernetes version: 1.27.1
To Reproduce
Steps to reproduce the behavior:
Deploy Weave GitOps.
Create a Secret oidc-auth in the Weave GitOps Namespace configured for Azure AD with the claimUsername set to sub.
Log into Weave GitOps.
Click on the upper-right icon to open the drop-down menu.
Expected behavior
The menu says "Hello, Max Jonas Werner"
Actual Behavior
The menu says "Hello, tRbZ..."
Additional Context (screenshots, logs, etc)
Weave GitOps should hit up the UserInfo endpoint and fetch the user's actual name. Alternatively it could see if it finds that information in the ID token but that's not a given depending on the OIDC provider's configuration.
The text was updated successfully, but these errors were encountered:
@makkes - Do you have any documentation on how to wire flux to Azure AD (App Registrations etc)? I'm not sure what to put in the oidc-auth secret ( I have client id, client secret, issuer with tenant id, etc)
Describe the bug
When logging in at Weave GitOps with Azure AD configured as OIDC provider, then the
sub
claim which is the recommended way to identify users in Azure AD is also used as the user's name:Environment
To Reproduce
Steps to reproduce the behavior:
oidc-auth
in the Weave GitOps Namespace configured for Azure AD with theclaimUsername
set tosub
.Expected behavior
The menu says "Hello, Max Jonas Werner"
Actual Behavior
The menu says "Hello, tRbZ..."
Additional Context (screenshots, logs, etc)
Weave GitOps should hit up the UserInfo endpoint and fetch the user's actual name. Alternatively it could see if it finds that information in the ID token but that's not a given depending on the OIDC provider's configuration.
The text was updated successfully, but these errors were encountered: