Deploying Langfuse with Azure Active Directory authentication:

When deploying Langfuse via Helm with Azure Active Directory authentication for its users, recommendations and preferences mainly focus on correct Azure AD configuration, security practices, and provider settings. There does not appear to be a major preference for one Helm chart over another—the official Langfuse Helm chart is the standard. The following best practices and considerations are recommended.

1. Use the official Langfuse Helm chart for Kubernetes deployment and set the Azure AD provider configuration in values.yaml as per Langfuse documentation.

2. Supply the Azure AD client ID, client secret, and tenant ID as environment variables or as Helm chart values to ensure correct SSO setup. For example,

nextauth:

  secret:

    value: "<your-nextauth-secret>"

  providers:

    azure-ad:

      enabled: true

      clientId: "YOUR_CLIENT_ID"

      clientSecret: "YOUR_CLIENT_SECRET"

      tenantId: "YOUR_TENANT_ID"

Ideally, the clientId, clientSecret, and tenantId would be stored as Kubernetes secrets and references in the values.yaml file.

3. Set the OAuth Callback URL in your Azure AD application to /api/auth/callback/azure-ad and confirm it matches your deployed application's endpoint. The OAuth redirect URI must be kept in sync between Azure AD, the Helm values, and the deployed Langfuse instance to ensure proper authentication flow.

4. Disable other authentication providers when going with one of the providers such as Azure AD.

Langfuse provides role-based access control (RBAC) that works with SSO authentication providers like Azure Active Directory (Azure AD), enabling fine-grained authorization for users in your organization. Langfuse can be deployed so that only Azure AD users belonging to a specific Azure AD group are allowed to log in and access the UI. Roles can be assigned at both the Organization (“Owner”, “Admin”, “Member”, “Viewer”, “None”) and Projects isolations scopes.

Azure AD Group Membership can be enforced for Langfuse UI access by registering Langfuse as an application in Azure AD and specifying users and groups on the Azure portal page to manage it. That same Enterprise Application must have Microsoft Graph “GroupMember.Read.All” and included in AD App permissions with Admin Consent property set. Register a custom handler that validates the token and its claims from the redirect received from Microsoft AD to ensure that the user is part of the group.

This would look something like this:

import AzureADProvider from "next-auth/providers/azure-ad";

const REQUIRED_GROUP_ID = process.env.AZURE_AD_REQUIRED_GROUP_ID;

export const authOptions = {

  providers: [

    AzureADProvider({

      clientId: process.env.AZURE_AD_CLIENT_ID,

      clientSecret: process.env.AZURE_AD_CLIENT_SECRET,

      tenantId: process.env.AZURE_AD_TENANT_ID,

      // Ensure you add "groups" claim in Azure AD app registration token configuration!

    }),

    // ...other providers

  ],

  callbacks: {

    async signIn({ user, account, profile }) {

      // The "groups" claim is present in profile if Azure AD is configured to emit it

      const allowedGroups = profile.groups || [];

      // You may also need to handle profile.groups as string array or as object depending on Azure config

      if (allowedGroups.includes(REQUIRED_GROUP_ID)) {

        return true;

      }

      // Optionally log denied access attempts

      return false;

    },

    // Optionally pass group data into the session

    async session({ session, token }) {

      session.groups = token.groups || [];

      return session;

    },

    async jwt({ token, account, profile }) {

      if (profile?.groups) {

        token.groups = profile.groups;

      }

      return token;

    },

  },

};

// Export NextAuth handler:

export default NextAuth(authOptions);

This would then be deployed on the Langfuse’s instance via a configmaps like this:

apiVersion: v1

kind: ConfigMap

metadata:

  name: langfuse-nextauth-patch

data:

  patch-nextauth.ts: |

    // (The TypeScript patch code from above is inserted here)

And

a volume and mount for the ConfigMap are added to the langfuse-web pod's deployment spec:

spec:

  containers:

    - name: langfuse-web

      # ...existing config...

      volumeMounts:

        - name: nextauth-patch

          mountPath: /app/pages/api/auth/patch-nextauth.ts

          subPath: patch-nextauth.ts

  volumes:

    - name: nextauth-patch

      configMap:

        name: langfuse-nextauth-patch

Here, a caveat must be mentioned that an init container, startup hook, or a custom entry script to overwrite/meld patch-nextauth.ts on the […nextauth].ts file, depending on the chosen image build and deployment workflow. Alternatively, a custom image can be build using this file as a replacement in the application source tree, referencing the ConfigMap as the build context.

#codingexercise: Drone-aerial-images-count.py.docx