SAML and OAUTH federated logins not working on 24.6.0 about authentik HOT 5 CLOSED

I've found the source of the pickling error.

This line could become

        flow_manager.policy_context["saml_response"] = tostring(self._root)    

I don't see anywhere in the code that a "saml_response" context is accessed, so this is a future-compatible method to 'pre-serialize' back into XML form.

With these fixes, both SAML and OAuth are working as expected now.

I'll try to make this into a PR when I have the time. The SAML source is also much more useful if some of the abstracted response entry names are mapped back into semantic names. Here is some code that is doing that well for me, that I will also include in the PR. In particular, this gets the email out of a university Shibboleth implementation, allowing a mapping into my Authentik instance. (Sorry about the line numbers)

    def prepare_flow_manager(self) -> SourceFlowManager:
        """Prepare flow plan depending on whether or not the user exists"""
        name_id = self._get_name_id()
        # Sanity check, show a warning if NameIDPolicy doesn't match what we go
        if self._source.name_id_policy != name_id.attrib["Format"]:
            LOGGER.warning(
                "NameID from IdP doesn't match our policy",
                expected=self._source.name_id_policy,
                got=name_id.attrib["Format"],
            )
        # transient NameIDs are handled separately as they don't have to go through flows.
        if name_id.attrib["Format"] == SAML_NAME_ID_FORMAT_TRANSIENT:
            return self._handle_name_id_transient()

        attr_values = delete_none_values(self.get_attributes())
        # mapping of SAML abstracted oids into semantic names. This should probably be factored into constants.py
        attr_map = {
            'urn:oid:0.9.2342.19200300.100.1.3' : 'email',
            'urn:oid:2.5.4.42': 'firstname',
            'urn:oid:2.5.4.4': 'lastname',
            'urn:oid:2.16.840.1.113730.3.1.241' : 'displayname'
        }
        # expand the map
        for k, v in list(attr_values.items()):
            m = attr_map.get(k, None)
            if m is not None:
                attr_values[m] = v
        #print("saml name: ", attr_values)
        flow_manager = SAMLSourceFlowManager(
            self._source,
            self._http_request,
            name_id.text,
            attr_values,
        )
        flow_manager.policy_context["saml_response"] = tostring(self._root)
        return flow_manager

from authentik.

I think I see where this issue might be arising.

There used to be

            new_connection = self.update_connection(new_connection, **kwargs)
            new_connection.save()
            return Action.LINK, new_connection

this also occurs on line 149.

and now the new_connection.save() call is missing in newer versions. Was it factored into update_connection only for certain sources?

from authentik.

I can now confirm that adding these lines back in has fixed the issue for me.

from authentik.

So the pickle error shouldn't happen anymore in 2024.6 since the cause of it was caching the planned flow, which is disabled here: 833c66a

It would probably still be safer to wrap saml_response back into a string, but to a degree that makes it harder to do anything with (and yes, it was indeed added as an object that can be used in policies, authentik doesn't use it itself by default)

The link not being saved is an actual bug, we've changed the saving behaviour to only save the connection through a dynamic stage injected into the flow, but of course when initiating the link from the user settings there isn't a flow where that stage can run

For mapping SAML source data, this will be much easier with #8771

from authentik.

I was still getting a pickling error in 2024.6 even with that caching disabled from 833c66a. I checked and my copy did have those lines disabling the caching.

I think there is some other point where it is caching or passing flow details to a worker or logging system. I couldn't get a backtrace to determine what was triggering the pickle on 2024.6 though.

from authentik.