This discussion is archived
10 Replies Latest reply: Feb 15, 2012 11:46 AM by DrClap RSS

Using Cookies to Transfer Between Separate Servlet Containers

916823 Newbie
Currently Being Moderated
Hello,

I'm working on a SSO facility to enable users to login to a portal which uses a remote IdP.

The steps go as follows:

-The user connects to the authentication webapp in Servlet Container A. (Let's say the domain is my.domain/portal)
-The authentication process completes and now has a unique identifier (and E-mail address) for the user
-The webapp redirects the user to the portal, which is installed in a separate Servlet Container B. (Domain my.domain:8585)

Since they're in separate Servlet Containers using HttpServletRequest Attributes isn't an option.
Adding separate HttpServletRequest Headers seems to be a fairly complex solution

So I decided to use Cookies, but while I am able to add the cookie to the session, it isn't being received by the portal.

I feel like I'm missing something but haven't been able to figure out what it is. Any ideas?
  • 1. Re: Using Cookies to Transfer Between Separate Servlet Containers
    DrClap Expert
    Currently Being Moderated
    Normally a web domain can't look at the cookies for another web domain. It's a basic security feature. However I believe there is a way for domains to share cookies, so I suggest you look into that.
  • 2. Re: Using Cookies to Transfer Between Separate Servlet Containers
    916823 Newbie
    Currently Being Moderated
    The domain is the same for both Servlet Containers, they're just on separate ports. Is that enough to make them count as separate for purposes of sharing cookies?

    If so, then where's a good resource for reading up on getting separate domains to share cookies? None of the examples or discussions I've found online address that scenario.
  • 3. Re: Using Cookies to Transfer Between Separate Servlet Containers
    DrClap Expert
    Currently Being Moderated
    user8737743 wrote:
    The domain is the same for both Servlet Containers, they're just on separate ports. Is that enough to make them count as separate for purposes of sharing cookies?
    I don't know. That would be part of the research that you're going to do.
    If so, then where's a good resource for reading up on getting separate domains to share cookies? None of the examples or discussions I've found online address that scenario.
    I found that the Google keywords "cookie domain share" appeared to be a good resource.
  • 4. Re: Using Cookies to Transfer Between Separate Servlet Containers
    916823 Newbie
    Currently Being Moderated
    I would venture to say posting on a forum like this would constitute part of that research. A useful answer would have been appreciated. Whether or not your second comment even applies hinges on the answer to my first question.

    Edited by: ArcticFox on Feb 13, 2012 6:48 AM
  • 5. Re: Using Cookies to Transfer Between Separate Servlet Containers
    gimbal2 Guru
    Currently Being Moderated
    I'm not going to start a debate with you what constitutes as research or even basic ethics; that right belongs to the good doctor and I'm sure he'll want to take the opportunity to respond to you on this matter.

    I want to take a step back and just look at what you have. You want to force some solution with HTTP request parameters and cookies to get some sort of SSO solution going. But is that really the way to go? If you look at for example a well-known SSO solution named OpenID, it works on a simple webservice basis. There is a known url where you communicate authentication requests to through basic (encrypted) HTTP calls and that centralized server keeps track of state.

    Key point: centralized web service. When I think about an SSO solution, that is the first thing my mind jumps too. But hey, your mileage may vary.
  • 6. Re: Using Cookies to Transfer Between Separate Servlet Containers
    916823 Newbie
    Currently Being Moderated
    gimbal2 wrote:
    I'm not going to start a debate with you what constitutes as research or even basic ethics; that right belongs to the good doctor and I'm sure he'll want to take the opportunity to respond to you on this matter.

    I want to take a step back and just look at what you have. You want to force some solution with HTTP request parameters and cookies to get some sort of SSO solution going. But is that really the way to go? If you look at for example a well-known SSO solution named OpenID, it works on a simple webservice basis. There is a known url where you communicate authentication requests to through basic (encrypted) HTTP calls and that centralized server keeps track of state.

    Key point: centralized web service. When I think about an SSO solution, that is the first thing my mind jumps too. But hey, your mileage may vary.
    Thanks for the feedback. Actually, I've gotten it working as of this morning. What I've been doing is mainly a POC solution so it still has a good deal of refining and tweaking before it's something I'd put into production. Eventually web services will become involved once I start the next phase of the project. For now, all I really needed was the simplest approach so that we could have a firm basis to proceed.

    I'm not looking for a debate, either. All I wanted was the answer to the question of whether specifying a port number would result in the cookie being treated as if it were from a separate domain. (Turns out, the answer is no. I suspected that to be the case, but when you're trying something out for the first time you can't take anything for granted.)
  • 7. Re: Using Cookies to Transfer Between Separate Servlet Containers
    DrClap Expert
    Currently Being Moderated
    ArcticFox wrote:
    I would venture to say posting on a forum like this would constitute part of that research.
    Indeed it does.
    A useful answer would have been appreciated.
    But as I said, I don't have one for you. I could have gone and looked it up; but so could you, and you're the one who wants to know the answer. The experience which caused you to post here already suggests an answer to that question, but of course it might be more complicated than just "yes or no". Hence the need for more research.

    And really, it isn't that hard to find out about cookies. If I had been interested in the topic I might have spent some time reading up on them myself, and then posting your answer here. But I wasn't that interested, so I didn't. Which is completely within my rights as a forum user, so I decline to accept any shaming.
  • 8. Re: Using Cookies to Transfer Between Separate Servlet Containers
    ramp Explorer
    Currently Being Moderated
    By default, cookies are only returned to the server that sent them. You could however set the domain of the cookie to a sub domain value and then the cookie would be sent to all servers in that sub domain.

    Thus for example a cookie sent from a server say a.b.com will normally be sent back only to a.b.com because the domain of the cookie would be by default 'a.b.com'. However if the domain of the cookie were to be set to the sub-domain '.b.com', then that cookie would be sent to all servers in that sub domain. Thus 'a1.b.com', 'a2.b.com' etc would all receive the cookie in requests sent from the browser.
  • 9. Re: Using Cookies to Transfer Between Separate Servlet Containers
    916823 Newbie
    Currently Being Moderated
    DrClap wrote:
    But as I said, I don't have one for you. I could have gone and looked it up; but so could you, and you're the one who wants to know the answer. The experience which caused you to post here already suggests an answer to that question, but of course it might be more complicated than just "yes or no". Hence the need for more research.
    Then why bother to answer at all? I'm not being rhetorical here, and I don't mean to drag out an argument but this needs to be said. If somebody posts to a forum like this one with a question like that, it may be that they're frustrated, up against a deadline, etc. What they don't need is to be told "Go do the research." That answer comes across, whether you mean it to or not, as pretty smug. Besides which, it seems to assume the person posing the question isn't exploring any other avenues besides this one, which is an illogical assumption to make.
    DrClap wrote:
    And really, it isn't that hard to find out about cookies. If I had been interested in the topic I might have spent some time reading up on them myself, and then posting your answer here. But I wasn't that interested, so I didn't. Which is completely within my rights as a forum user, so I decline to accept any shaming.
    Finding out about cookies is easy, generally speaking. That's not the same as making it easy to find the answer to specifics about an actual application. Nobody was asking you to read up on it. It was a simple question that merited a simple answer. Another of your rights as a poster is to refrain from posting an answer at all if you can't be helpful.

    I've spoken my peace on the matter.

    ramp wrote:
    By default, cookies are only returned to the server that sent them. You could however set the domain of the cookie to a sub domain value and then the cookie would be sent to all servers in that sub domain.

    Thus for example a cookie sent from a server say a.b.com will normally be sent back only to a.b.com because the domain of the cookie would be by default 'a.b.com'. However if the domain of the cookie were to be set to the sub-domain '.b.com', then that cookie would be sent to all servers in that sub domain. Thus 'a1.b.com', 'a2.b.com' etc would all receive the cookie in requests sent from the browser.
    Thanks. In this case the domains were the same, but the requests were going over separate ports. It's working great now. :)

    Edited by: ArcticFox on Feb 15, 2012 11:22 AM
  • 10. Re: Using Cookies to Transfer Between Separate Servlet Containers
    DrClap Expert
    Currently Being Moderated
    ArcticFox wrote:
    DrClap wrote:
    But as I said, I don't have one for you. I could have gone and looked it up; but so could you, and you're the one who wants to know the answer. The experience which caused you to post here already suggests an answer to that question, but of course it might be more complicated than just "yes or no". Hence the need for more research.
    Then why bother to answer at all?
    I answered because I had a partial answer. True, I didn't have the entire answer, but I could at least point at the root cause of the problem. I assumed (or rather hoped) that you could take it from there, having been pointed in the right direction. And you did.
    It was a simple question that merited a simple answer.
    I'm not going to comment on the rest of what you said, because I agree that we're satisfied. However let me just point out that this is a hopelessly naive idea. Simple questions rarely have simple answers, as I'm sure you will agree if you take a minute to think of a couple of simple questions.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points