June 13, 2017 at 9:46 am #17676
do you know if it’s possible to auto login a user if this user has a valid session on openam for a service1 and go to the second service2 ?
As a user, I go to site1 , i click on the login button and i’m redirect to our sso (openam). After login i’m automaticaly redirected to the site1.
Some minutes after, i go to site2 (public website), and i would like to be “automatically authentified” because i have a valid SSO session.
PS: it’s not possible to reuse the cookie has we use different domain ;-)
thanks for your help.June 13, 2017 at 10:38 am #17679
If you are using different cookie domains, then SSO by definition is not really possible OOTB.
You can write custom code however that makes sure that the session cookie issued to domain X is re-created for domain Y. The gist of the solution would be to access a JSP on domain X that can read the cookie for site1 and it redirects the user to domain Y with the session ID as an encrypted/secure query parameter, at which point the JSP can set the cookie for domain Y.
Bit hacky, but should work. Doesn’t scale too well though.June 13, 2017 at 10:52 am #17681
@peter-major, to get this clear in my head, does this solution not depend on custom JSPs on both domain X and domain Y? The one on domain X (where the SSO platform is) reads the cookie and forwards to domain Y with the session ID on the URL as you describe. Something on domain Y needs to understand the parameter and set the domain Y cookie, though? If that’s the case, and therefore the OP has some control over the ‘site2’ website on domain Y to deploy custom code. If so, why not use an agent and the built-in CDSSO mechanism?
AndyJune 13, 2017 at 11:00 am #17682
@acorysmart421-com thanks, I think I have misread the original requirement. My solution was provided for this scenario:
* OpenAM is on both domain X and domain Y
* site1 sends users to domain X of OpenAM
* site2 sends users to domain Y of OpenAM
In this scenario the JSP would be on both domains by definition, because it would be part of the OpenAM application.
To cover this scenario:
* OpenAM is on domain X
* site1 is on domain Y
* site2 is on domain Z
To ensure that after successful authentication on site1, site2 will be aware of the already established session just read through this thread:
https://lists.forgerock.org/pipermail/openam/2015-March/040285.htmlJune 13, 2017 at 11:35 am #17685
Thanks Peter, I understand your solution for the first scenario now. And the thread covering the second scenario was interesting. Possibly the original requirement was one of these, and I misunderstood it – maybe the OP could clarify?
AndyJune 13, 2017 at 2:55 pm #17690
Firstly, thanks so much for your help.
My question concern the second case (1 openAm domain for 2 differents client site). Your link is very interresting and if i understand well, i have 2 solutions :
– Using CORS (how ?)
PS: i am in the same situation as the user in your thread, we use previously JASIG cas as SSO and it was possible to use a gateway parameter just to redirect the user and auto login if he has a valid session.
thanks a lotJune 13, 2017 at 4:38 pm #17695
I’ll bow to @peter-major‘s far greater knowledge here, I’ve not had a need to use cors or the solution outlined in the link yet. Now cors support is integral to OpenAM it would seem like that should be the first possibility to try.
AndyJune 13, 2017 at 4:59 pm #17696
thanks for example, i know how to configure cors, but in your example i don’t understand how OpenAM can figure out the username only from a rest request with idFromSessions (i suppose this is the session id on site 2 ? ).
or do you propose to share the iplanet session cookie to site2 and reuse this to check if user is logged ?
from my point of view, it’s not secured to extend the visibility of this cookie to other domains (not only openam sub-domain).
thanksJune 14, 2017 at 8:40 am #17700
This is an example output from _idFromSession:
So your JS code sitting on site 2 will need to parse the JSON result of the AJAX call and use the value of the id field.
The REST endpoint in OpenAM really shouldn’t return the session ID in REST responses (if you want to implement a new REST endpoint in OpenAM on your own), because doing so would negate the purpose of HttpOnly cookies.
You must be logged in to reply to this topic.