No JSESSIONID session cookie in the redirect url request header when using Apigee proxy

[Biswa_2022]

Scenario 1: Working fine The application receives all the requests through Azure App Gateway. The application sets some value for the session cookie "JSESSIONID" in the response of first "/login" endpoint (set by Spring security). This same JSESSIONID cookie value is then used in the request header of "/login?code=<some_code>&state=<some_state>" api, which is the callback url from the Authorisation server. So, in this case, the auth server is able to identify the client based on same session cookie value. We can infer that Azure app Gateway sends the cookie forward. There is no specific settings done in App Gateway.

Scenario 2: Issue Now the application receives the request through Azure App Gateway from Apigee. The callback url is also set to the apigee url. The application sets some value for the session cookie "JSESSIONID" in the response of first "/login" endpoint. But when the callback url "/login?code=<some_code>&state=<some_state>" is invoked after Auth server validation success, there is no "JSESSIONID" in the request header. So, possibly Apigee is stripping of this cookie.

The other cookies like "SameSite", "ADRUM_BTa" and "ADRUM_BT1" are passed in the request header of the callback url in both the scenarios.

Could someone please help here, if there is any settings change that needs to be done in Apigee so that it sends the cookie in the request header of callback url.

Any help would be highly appreciated.

Thanks in advance.

[miguelmendoza]

@Biswa_2022 ,

Can you post sequence diagrams for both scenarios? (showing each actor: the client, Spring Servlet, Apigee, Authorization Server, etc). That would help to understand what is going on.


One thing I would say that the "Set-Cookie" behavior is very finicky, specially when being done as part of an HTTP Redirect, as the cookie domain and the cookie origin might not match, so browser could reject the cookie.

[dchiesa1]

> the cookie domain and the cookie origin might not match, so browser could reject the cookie.

Yes. And even if the browser accepts the cookie, it may not replay the cookie in the subsequent call, if the domain or the path on the cookie does not match the domain or path on the subsequent call (/login). This would be consistent with the observed behavior.

But when the callback url "/login?code=<some_code>&state=<some_state>" is invoked after Auth server validation success, there is no "JSESSIONID" in the request header. So, possibly Apigee is stripping of this cookie.

Before you can conclude that Apigee is stirpping the cookie, you'd have to examine the response that Apigee sends back and also examine the response the browser receives. You can do the former easily in Apigee trace, and the latter in the brower devtools "network" tab.

[Biswa_2022]

Hi @dchiesa1 , @miguelmendoza 

Thanks for the replies and suggestions. Seems like cookie path was the main reason for this issue. This was resolved by setting the session cookie path in the Application equal to the URI backend path of the Apigee proxy configuration.

server.servlet.session.cookie.path=/backend/path/configured/in/apigee/proxy

As the session cookies are always set based on path. By default, without the above code, the session cookie path was set to the server context path of the application, which was different to the backend path of Apigee proxy setting, causing this issue.

Thanks again and cheers!!

Regards.