-
Notifications
You must be signed in to change notification settings - Fork 372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add domain allowlist #1237
base: main
Are you sure you want to change the base?
Add domain allowlist #1237
Conversation
…e to restrict Google sign-in to specific domains
…ngfuse app This commit adds a Cloud Build configuration file that specifies the steps for building and deploying the Langfuse app. The steps include building the Docker image, pushing it to a container registry, and deploying it to Google Cloud Run. The image that is built and deployed is "europe-west1-docker.pkg.dev/langfuse-test/langfuse/langfuse:latest".
…port Add google allowed domains support
…ate' instead of 'run deploy' command
The build and push steps for the Langfuse image have been re-introduced.
…port Add google allowed domains support
…e to restrict Google sign-in to specific domains
…ngfuse app This commit adds a Cloud Build configuration file that specifies the steps for building and deploying the Langfuse app. The steps include building the Docker image, pushing it to a container registry, and deploying it to Google Cloud Run. The image that is built and deployed is "europe-west1-docker.pkg.dev/langfuse-test/langfuse/langfuse:latest".
…ate' instead of 'run deploy' command
The build and push steps for the Langfuse image have been re-introduced.
@aablsk is attempting to deploy a commit to the langfuse Team on Vercel. A member of the Team first needs to authorize it. |
@marcklingen is there anything I can do to push this forward? |
Hi @aablsk, thanks again for your contribution on this and sorry for the delay. I understand that it is very unclear if we can extend this logic to AzureAD, thereby Langfuse might get less secure when this setting is misinterpreted. Until now, I recommended teams to restrict the OAuth app they create to their own google workspace account or AzureAD tenant. Thereby the OAuth app itself blocks all external users. I think this is secure and I'd probably go for adding this to the docs and closing this PR. What do you think? Is there a case that would require |
Thank you for getting back to me, @marcklingen! 🙇
I agree, which is why I originally proposed only adding this logic for the Google provider with a google-specific domain allow-list.
Unfortunately, for us this is not an option as we need to allow different domains that belong to multiple Workspace accounts due to the infrastructure setup of the business organisation in which we're embedded. This might be just a corner case, which means that we're happy to continue with maintaining our own fork. |
Thanks for the clarification and then let's add this to Langfuse (maintaining a fork isn't fun). I'd suggest to go for AUTH_GOOGLE_ALLOWED_DOMAINS and only apply this flag to Google users to make sure this is not misunderstood leading to decreased security. What do you think? |
…fuse into allowed-domains
@marcklingen I've updated the code to only work for the Google authentication and tests are green 🚀 We would highly appreciate it, if this could make it into one of the next releases 🤞 |
What does this PR do?
This PR introduces a new environment variable "AUTH_ALLOWED_DOMAINS" that acts as an "allowlist" for domains to login to the langfuse instance.
Motivation: I'd love a more secure way to onboard people for the self-hosted instance. A boolean toggle to turn off/on signups is insufficient for our requirements. Restricting signups to certain domain(s) is sufficient for CHAPTR's requirements.
🚨 Important security considerations 🚨
This domain allowlisting has certain nuances to it, depending on the provider used.
AUTH_DISABLE_USERNAME_PASSWORD
is not set totrue
as there is no email verification. Anyone with knowledge of the allowed domains could still sign up with a non-existent email as long as the email's string has an allowed domain in it.hd
claim on theprofile
as this seems to be the only secure way to validate the domain according to this Github Thread.UI considerations
Currently, if the sign-in fails, the following screen is shown, which does not adhere to the langfuse visual identity:
Type of change
Mandatory Tasks
Checklist
✅ I haven't read the contributing guide
✅ My code doesn't follow the style guidelines of this project (
npm run prettier
)✅ I haven't commented my code, particularly in hard-to-understand areas
✅ I haven't checked if my PR needs changes to the documentation
✅ I haven't checked if my changes generate no new warnings (
npm run lint
)❌ I haven't added tests that prove my fix is effective or that my feature works
-> I'd like to understand which tests and what coverage would be expected for this feature
🤷 I haven't checked if new and existing unit tests pass locally with my changes (same number of tests fail before and after the change for me locally)