[Bug] appflowy not work with authentik

[anschein]

I'm trying to use authentik as a saml provider, authentik is a third party open source authentication system that works well with my other services, I also checked the saml output endpoints of authentik and it is able to generate the xml metadata correctly, but I'm populating the metadata address into appflowy The following error is thrown when adding the saml provider:

2024-12-21T04:17:40Z INF component=api error=400: HTTP 406 error fetching SAML Metadata from URL 'https://example.com/api/v3/providers/saml/8/ metadata/' method=POST msg=400: HTTP 406 error fetching SAML Metadata from URL 'https://example.com/api/v3/providers/saml/8/metadata/' path=/ admin/sso/providers referer=appflowy-flutter:// remote_addr=172.30.0.10 request_id=ad452403-acaf-48f0-9897-962aa9343cbd

The xml output of the authentik endpoint is as follows:

{"metadata":"<md:EntityDescriptor xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#\" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#\" ID="_19222da8cefbc5daf734bef3c753f512a48a21b0581f1dd6778fa7dd43e1d57d" entityID="authentik"><md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://example.com/application/saml/appflowy/slo/binding/redirect/\"/><md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://example.com/application/saml/appflowy/slo/binding/post/\"/>md:NameIDFormaturn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>md:NameIDFormaturn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>md:NameIDFormaturn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>md:NameIDFormaturn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://example.com/application/saml/appflowy/sso/binding/redirect/\"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://example.com/application/saml/appflowy/sso/binding/post/\"/></md:IDPSSODescriptor></md:EntityDescriptor>"}

[khorshuheng]

We are using Supabase Auth to handle the SAML 2.0 flow. When adding a new SSO provider, the following function is called:
https://github.com/supabase/auth/blob/v2.159.1/internal/api/ssoadmin.go#L176

It is assumed that the response is in xml format, as opposed to json format.

I will check if there is a way to retrieve the data in xml format.

[khorshuheng]

After looking through the Authentik source code, this is my hypothesis:

Authentik uses Django framework. By default, Django framework has the following rederer:

REST_FRAMEWORK = {
    'DEFAULT_RENDERER_CLASSES': [
        'rest_framework.renderers.JSONRenderer',
        'rest_framework.renderers.BrowsableAPIRenderer',
    ]
}

When an Accept header is passed from the client, such as what happens here in Supabase Auth, Django will check the renderer classes to see if it is supported. Unfortunately, Django doesn't support XML by default, a plugin is required to add the support. From my preliminary investigation it doesn't appear that Authentik uses this plugin.

Therefore, the response 406 is returned, because there's no renderer class that can handle the xml type.

Ironically, if the caller doesn't include the Accept header, Authentik does provide the response with content type = "application/xml" .

It is possible to reproduce this issue via curl:
curl -v "http://localhost:9080/api/v3/providers/saml/1/metadata/?download" -H "Accept: application/xml"
vs
curl -v "http://localhost:9080/api/v3/providers/saml/1/metadata/?download"

[khorshuheng]

I have also raised an issue here: goauthentik/authentik#12483 .

[anschein]

Thank you very much for your enthusiastic support, at the moment it looks like the only way to make authentik work in conjunction with appflowy cloud is to wait for authentik to fix the issue, hopefully it won't be too long a wait, in my environment there are about 5-10 people using my home server, and to be able to add appflowy I'm sure would be a big step forward for me

[khorshuheng]

Actually, there is another way. If you have some experience in Golang and building docker image, you can simply modify the gotrue code base such that the "Accept" header is not sent, then build a new image. You will also need to update the metadata URL from /metadata to /metadata/?download