You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can see another call to the IDP login which succeeds. Below is the screenshot -
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%
The text was updated successfully, but these errors were encountered:
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!
Uh oh!
There was an error while loading. Please reload this page.
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 -

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

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%
The text was updated successfully, but these errors were encountered: