Closed FrostKiwi closed 1 year ago
RelayState should be sent by Weblate to SAML IdP and then back to Weblate after authentication. You can check this is happening in your browser developer tools (Network tab). My wild guess would be that there is some redirect on the way which discards it.
This issue has been marked as a question by a Weblate team member. Why? Because it belongs more to the professional Weblate Care or community Discussions than here. We strive to answer these reasonably fast here, too, but purchasing the support subscription is more responsible and faster for your business. And it makes Weblate stronger as well. Thanks!
In case your question is already answered, making a donation is the right way to say thank you!
RelayState should be sent by Weblate to SAML IdP and then back to Weblate after authentication. You can check this is happening in your browser developer tools (Network tab). My wild guess would be that there is some redirect on the way which discards it.
The very first request sent by Weblate after clicking the Login with SAML button is this 302 redirect: Followed by the next reply being from Microsoft, with the error message HTML:
@nijel So the theory goes, that this very first request doesn't make it somehow?
So theory is: Weblate's python-social-auth
makes the request, which makes it to microsoft, but microsofts reponse does not make it back? Our service is not reachable from the internet btw, intranet only.
Maybe Azure doesn't like that the return URL is not public? I have no clue, but this merely looks like a configuration/incompatibility issue on Azure side as it doesn't redirect back to Weblate to process authentication claim.
Maybe Azure doesn't like that the return URL is not public? I have no clue, but this merely looks like a configuration/incompatibility issue on Azure side as it doesn't redirect back to Weblate to process authentication claim.
Just confirmed, that there are other SAML users with non-public URLs. This is supposed to work even without public URLs, intranet only.
Let's check the following first:
@nijel could you confirm or refute the following:
<Weblate Domain>/accounts/complete/saml
is supposed to throw an exception if you navigate to that view.
MultiValueDictKeyError
is the expected outcome of proper Weblate SAML configuration if you paste that URL into the browser.
That endpoint is supposed to be used only in the authentication flow and RelayState is supposed to be present there, so crashing is how it ends up. There is an upstream issue for this as well: https://github.com/python-social-auth/social-core/issues/632
Ah, there actually is also PR to covert this to missing error: https://github.com/python-social-auth/social-core/pull/818
This issue has been automatically marked as stale because there wasn’t any recent activity.
It will be closed soon if no further action occurs.
Thank you for your contributions!
The crash will no longer happen with https://github.com/python-social-auth/social-core/pull/818
Describe the issue
We have an issue configuring
SAML
to work with Azure logins. It seems that the login works on a theoretical level, as Azure detects a successful login. But Weblate has a view throwing an exception, which kills the login process, causing Microsoft to throw an exception about a malformatted message. Any idea how to debug this?The XML SAML info generated by
https://<redacted>.net/translate/accounts/metadata/saml/
contains the URLLocation="https://<redacted>.net/translate/accounts/complete/saml/"
forAssertionConsumerService Binding
. This URL is called by Azure and errors out. If you navigate there, you are greeted with the ExceptionMultiValueDictKeyError at /translate/accounts/complete/saml/
. Full traceback and screenshot below. The login process itself errors out with Microsoft's login service throwing the exception:AADSTS20012: An error occurred when we tried to process a WS-Federation message. The message was invalid, malformatted, or contains potentially dangerous characters.
, screenshot below.The configuration can be seen in the traceback, but here is the relevant SAML part:
Just for reference, the attributes as setup in Azure:
I already tried
Steps to reproduce the behavior
Configure SAML with the versions and config mentioned
Expected behavior
Login succeeding
Screenshots
Exception traceback
How do you run Weblate?
weblate.org service
Weblate versions
Weblate deploy checks
No response
Additional context
No response