Please note that I have not tried to set something like this up, but I
think I might prefer a proper SSO solution to reduce the fragility, but
this is just my 2 cents.
First, in order to use the same cookie for both sling instances, the cookie
domain and path must be sent by the server from both sling instances with
values that are common to both instances. If you have the exact same
hostname for both endpoints and are only using the request path to route
the requests to the right place then the default cookie domain is probably
ok, but you would need to ensure the cookie path was "/" or some context
path that matches both endpoints or the browser won't send the cookie to
the other server.
Second, the servlet container is unlikely to just accept a cookie with a
sessionId that it didn't create. If the sessionId value doesn't match
something that the server-side session manager is already managing then it
would likely just ignore it and create a fresh session with a new
sessionId. So in order to workaround that you would probably need some
sort of session replication system that persists the session data to a
shared database. If both of the sling instances are pointing at the same
session persistence database then it may accept it? The session data in a
shared database may have it's own quirks related to concurrency,
serialization, and data conflicts that may make it not practical.
Third, you may run into some troubles with server-side session expiration.
For example, consider this scenario:
1. Your client interacts with tenant1 first to establish a session
2. The client then switches to working with tenant2 without any further
interaction with tenant1
3. After 30 minutes if inactivity, the session manager on tenant1 decides
that the session has expired and throws it away
4. The next request to tenant2 may then discover that the user is no longer
logged in due to #3 destroying the persisted session data from the shared
database.
Anyways, to me I think you may have less troubles using a SSO solution to
identify the user and allow each sling instance to manage their own
sessions independently of each other.
Regards,
Eric
On Tue, Dec 11, 2018 at 7:16 AM Jason E Bailey wrote:
> I'm going to start talking and saying things, and if I come across like
> I'm being pedantic I apologize in advance :)
>
> First, when we talk about logging in, we're talking about cookies. A
> cookie is used to identify a Session or store user credentials. You can't
> have a server side session or login without some form of cookie.
>
> In the case that you are describing a cookie that is assigned to the URL
> will be accessible by both servers, because regardless of the number of
> servers being used, the client see's only one end point. So putting a
> cookie on cms.example.org will be accessible from all instances that are
> serving content for that URL.
>
> So a SSO solution is overkill in this scenario. Single Sign On is good for
> logging into multiple URL's at once where once cookies have to be created
> multiple times.
>
> It comes back to what the multiple instances know.
>
> What I mean by that, does the content server know the user's and groups
> associated with the users? Does it do fine grain permission? Or does it
> really need to know is that this request is a logged in user or not?
>
> Scenario:
> Content server only needs to know that the request is a logged in user or
> not - When the user Logs in he get's a cookie that contains an encrypted
> string with an expiration date, maybe an IP address. There is then a
> common secret key used between the back end servers that the content server
> only needs to check to see that the cookie is a valid cookie.
>
> Scenario
> Content server not only needs to know that it's a valid cookie, but that
> the user is Joe and Joe is part of the User group and the user group is
> only permitted to know certain sections of the site. In that case you have
> the option of encoding additional information into the encrypted cookie or
> you have the cookie be a UUID that can reference another backend service
> that actually provides the details that I just mentioned. Which could then
> be cached for the life of the login.
>
> Does any of that help?
> - Jason
>
> On Sun, Dec 9, 2018, at 9:41 AM, Ruben Reusser wrote:
> > Jason,
> >
> > sorry, I should have been clear about what I am looking for
> >
> > 1 apache server, 1 domain name (say cms.example.org)
> > 2 sling instances (either on 2 servers or 2 different ports)
> >
> > from a user point of view I'd like to log in to cms.example.org and be
> > fully logged in to both sling instances (eg same full sling user on both
> > systems)
> >
> > one way of course would be to use an sso solution
> > another one would be that the authentication session in sling can be
> > shared between multiple instances
> >
> > what I am trying to get to is the following:
> >
> > - my cms uses one instance for the admin shell
> > - we use client side
