Skip to content

Cookies not getting set during SP initiated SSO #357

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
GitHub87 opened this issue Mar 25, 2021 · 1 comment
Closed

Cookies not getting set during SP initiated SSO #357

GitHub87 opened this issue Mar 25, 2021 · 1 comment

Comments

@GitHub87
Copy link

GitHub87 commented Mar 25, 2021

Issue description -

During SP(my webapplication) initiated SSO the call - http://openam-01.domain.com:8080/openam/SSORedirect/metaAlias/idp does not redirect back to my application. Below is a screenshot from the dev tools -
image

I can see another call to the IDP login which succeeds. Below is the screenshot -
image

Now the only difference that I see between the two request/response is that for the successful IDP "login" call the cookies are getting set whereas the actual SSO call does not have the AM auth cookies. I am not sure why this happens. But the moment I copy the request url from the failed IDP call, paste it in the browser and hit go(i.e. when it is a normal GET call).... AM is able to successfully validate and redirect me to where it needs to go. I checked that successful GET call and again saw that the cookies were set in there properly.

Does this mean that the idp call fails because of the absence of the cookies that AM is not setting properly? If so, how can this be resolved? The CoreSystem and other logs do not give any information for this failure.

My configuration -
Its a local setup - Windows OS.
openAM docker image - OpenAM 14.6.2 Build d3c90af (2021-February-08 15:11)
In openAM I have enabled CORS(using Tomcat CORS filter) and have set the com.sun.identity.cookie.httponly to true.
I have also set CATALINA_OPTS in my system variable - set CATALINA_OPTS=-Dcom.iplanet.am.cookie.name=iPlanetDirectoryPro -Dcom.sun.identity.federation.fedCookieName=fedCookie %CATALINA_OPTS%

@GitHub87
Copy link
Author

On further analysis on this we found out something. We are using the org.jboss.resteasy api for our servlet mapping in our application. It seems that AM fails silently when a servlet request is wrapped with the resteasy api. I tried to integrate the SSO logic with vanilla servlet code in our application and it worked. So we will be going with the plain servlets and bypass the resteasy api. Closing this issue here as a workaround is possible. Is there some documentation around this like if resteasy api's are compatible with AM currently or not, if not can this be included in the docs? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant