How to keep ory_kratos_continuity cookie through different domains?

[sebferrer]

Hi,

We currently have a question regarding our implementation of SAML in Kratos

At this point we can perform authentication via an external IdP (like an ADFS) and get a Kratos session via the identity of that IdP.

We are currently implementing the feature to initialize the SAML login flow. In the login page, we have a "SAML SSO Login" button. This button redirects us to our SAML login initialization route, thus redirecting us to our IdP.
After entering the login/password on this IdP, we are redirected to Kratos an error.

It turns out that we encounter the following errors in the Kratos code:

• key ory_kratos_saml_auth_code_session does not exist in cookie: ory_kratos_continuity
• the browser does not contain the necessary cookie to resume the session. This is a security violation and was blocked. Please clear your browser's cookies and cache and try again!

The key "ory_kratos_saml_auth_code_session" is the equivalent of "ory_kratos_oidc_auth_code_session" for our saml session.

As a result, the browser loses the information about the login flow and is unable to complete it correctly.

Here’s what we observe in our tests:

• The cookie is created on the Kratos side
• We go through our IdP
• The IdP sends us back to Kratos, but the cookie is not sent back, so we get a 400 error

I specify that when the IdP sends us back to Kratos, it’s not by a redirect but by an http POST, initiated from a page served by the IdP domain. I also specify that the IdP is on a different domain than Kratos.

Here's a video showing what's happening

On the other hand, if we reload by hand just after we see that the cookie is back.

It's really because we come back to Kratos via another domain that the cookie isn’t sent back. It seems to be a voluntary security on Kratos side, and it may come from the same_site=Lax

Here's the question: what would you recommend as an implementation to make sure the browser doesn't lose the login flow?

How is the cookie retained despite passing through an external IdP in OIDC? Is it because in OIDC it works through a redirect and not a POST?

We first considered not using cookies to transmit the login flow but abandoned the idea because otherwise we wouldn’t be able to use the Kratos ContinuityManager.

So here’s our current idea:

Since our SAML implementation in Kratos is based on the crewjam/saml library, we thought of using the same method as them to keep the cookies, namely set the same-site=None, with a lifetime for the cookie at 90s.

What do you think about it?

[aeneasr]

I think this is a problem with SameSite because of the redirection. Shouldn't this be similar to the OIDC flow? There the cookies should to work

[sebferrer]

Edit: So we're gonna modify the ContinuityManager to check the RelayState in addition to the continuity cookie, for the SAML case.

--

Unfortunately no, the HTTP-Redirect binding isn't recommended at all in the context of a SAML response. It's not even supported by Crewjam (and almost nobody).

"Since the length of URLs is limited in practice, the HTTP Redirect binding is suitable for short messages, such as the samlp:AuthnRequest message. Longer messages (e.g. those containing signed or encrypted SAML assertions, such as SAML Responses) are usually transmitted via other bindings such as the HTTP POST Binding."
https://en.wikipedia.org/wiki/SAML_2.0#HTTP_Redirect_Binding

The most used binding for the response is by far the HTTP-POST

Here's the usual SAML workflow: SP => HTTP-Redirect => IdP => HTTP-POST => SP

In SAML, the login flow data is supposed to persist through the RelayState and not through a cookie.

It's therefore impossible for us to make a flow similar to the OIDC one without changing the ContinuityManager code, hence our idea about a SAML specific continuity cookie with a SameSite=None and a lifetime of 90s.

So here are our questions:

• Can we propose a modification to the ContinuityManager so that it can check the RelayState in addition to the continuity cookie? This would allow us to follow the process expected by SAML but would imply adding code to the ContinuityManager.
• If not, is our idea of a SAML-specific cookie as mentioned above viable without becoming a security issue?
• Any recommendation about which way we should go?

[aeneasr]

If the IdP sends the HTTP POST request I don’t think that there is a way to have a cookie there - if I understand correctly. The first option sounds reasonable but I have very little code context to make a recommendation:/

[sebferrer]

Thank you very much for your answer, I think you gave us the information we needed. We will eventually talk about it again in the next PR update :)