[question] 2 sling instances behind one apache server sharing 1 session

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[question] 2 sling instances behind one apache server sharing 1 session

Ruben Reusser
hi there,

I have been trying to do the following: 1 apache http server, 2 sling
instances. /tenant1 goes to sling instance number 1, tenant 2 goes to
sling instance number 2. If I log in I'd love to be logged in to all
sling instances, preferably not with a cookie for each tenant. Would
love to hear suggestions in what direction I should concentrate my
effort to achieve my goal here!

thank you

Ruben

Reply | Threaded
Open this post in threaded view
|

Re: [question] 2 sling instances behind one apache server sharing 1 session

Jason E Bailey-2
Hi Ruben,

Can you clarify some, when you say two tenants, is this two separate domains ? And when you talk about being logged in, are yu controlling access or just validating that someone is logged in or not, i.e. being able to access information based on a user id.

- Jason

On Sun, Dec 2, 2018, at 10:04 AM, Ruben Reusser wrote:

> hi there,
>
> I have been trying to do the following: 1 apache http server, 2 sling
> instances. /tenant1 goes to sling instance number 1, tenant 2 goes to
> sling instance number 2. If I log in I'd love to be logged in to all
> sling instances, preferably not with a cookie for each tenant. Would
> love to hear suggestions in what direction I should concentrate my
> effort to achieve my goal here!
>
> thank you
>
> Ruben
>
Reply | Threaded
Open this post in threaded view
|

Re: [question] 2 sling instances behind one apache server sharing 1 session

Ruben Reusser
In reply to this post by Ruben Reusser
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 rendering for the admin shell
- content is stored in another instance

This approach should allow me to upgrade my admin shell (the whole admin
UI) without having to upgrade the instance containing the customer
content. It also would isolate each customer (or tenant) onto their own
(smaller) sling instance with their own JVM and hence allow for better
vertical or horizontal scaling

Ruben


Hi Ruben,

Can you clarify some, when you say two tenants, is this two separate domains ? And when you talk about being logged in, are yu controlling access or just validating that someone is logged in or not, i.e. being able to access information based on a user id.

- Jason
[show/hide original text]
On Sun, Dec 2, 2018, at 10:04 AM, Ruben Reusser wrote: > hi there, > > I
have been trying to do the following: 1 apache http server, 2 sling >
instances. /tenant1 goes to sling instance number 1, tenant 2 goes to >
sling instance number 2. If I log in I'd love to be logged in to all >
sling instances, preferably not with a cookie for each tenant. Would >
love to hear suggestions in what direction I should concentrate my >
effort to achieve my goal here! > > thank you > > Ruben >

Reply | Threaded
Open this post in threaded view
|

Re: [question] 2 sling instances behind one apache server sharing 1 session

Ben Fortuna-2
Hi Ruben,

If you are logged in to your sling CMS is it to author content? If so, how
do you maintain consistency when load balancing across two nodes?

If you are not authoring, is the session to authenticate custom CMS
extensions to sing? In such scenario general advice seems to be
externalising session completely as a separate session not integrated with
the sling session.

Regards,
Ben


On Mon., 10 Dec. 2018, 1:41 am Ruben Reusser <[hidden email] 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 rendering for the admin shell
> - content is stored in another instance
>
> This approach should allow me to upgrade my admin shell (the whole admin
> UI) without having to upgrade the instance containing the customer
> content. It also would isolate each customer (or tenant) onto their own
> (smaller) sling instance with their own JVM and hence allow for better
> vertical or horizontal scaling
>
> Ruben
>
>
> Hi Ruben,
>
> Can you clarify some, when you say two tenants, is this two separate
> domains ? And when you talk about being logged in, are yu controlling
> access or just validating that someone is logged in or not, i.e. being able
> to access information based on a user id.
>
> - Jason
> [show/hide original text]
> On Sun, Dec 2, 2018, at 10:04 AM, Ruben Reusser wrote: > hi there, > > I
> have been trying to do the following: 1 apache http server, 2 sling >
> instances. /tenant1 goes to sling instance number 1, tenant 2 goes to >
> sling instance number 2. If I log in I'd love to be logged in to all >
> sling instances, preferably not with a cookie for each tenant. Would >
> love to hear suggestions in what direction I should concentrate my >
> effort to achieve my goal here! > > thank you > > Ruben >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [question] 2 sling instances behind one apache server sharing 1 session

Jason E Bailey-2
In reply to this post by Ruben Reusser
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 rendering for the admin shell
> - content is stored in another instance
>
> This approach should allow me to upgrade my admin shell (the whole admin
> UI) without having to upgrade the instance containing the customer
> content. It also would isolate each customer (or tenant) onto their own
> (smaller) sling instance with their own JVM and hence allow for better
> vertical or horizontal scaling
>
> Ruben
>
>
> Hi Ruben,
>
> Can you clarify some, when you say two tenants, is this two separate
> domains ? And when you talk about being logged in, are yu controlling
> access or just validating that someone is logged in or not, i.e. being
> able to access information based on a user id.
>
> - Jason
> [show/hide original text]
> On Sun, Dec 2, 2018, at 10:04 AM, Ruben Reusser wrote: > hi there, > > I
> have been trying to do the following: 1 apache http server, 2 sling >
> instances. /tenant1 goes to sling instance number 1, tenant 2 goes to >
> sling instance number 2. If I log in I'd love to be logged in to all >
> sling instances, preferably not with a cookie for each tenant. Would >
> love to hear suggestions in what direction I should concentrate my >
> effort to achieve my goal here! > > thank you > > Ruben >
>
Reply | Threaded
Open this post in threaded view
|

Re: [question] 2 sling instances behind one apache server sharing 1 session

Eric Norman
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 <[hidden email]> 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 rendering for the admin shell
> > - content is stored in another instance
> >
> > This approach should allow me to upgrade my admin shell (the whole admin
> > UI) without having to upgrade the instance containing the customer
> > content. It also would isolate each customer (or tenant) onto their own
> > (smaller) sling instance with their own JVM and hence allow for better
> > vertical or horizontal scaling
> >
> > Ruben
> >
> >
> > Hi Ruben,
> >
> > Can you clarify some, when you say two tenants, is this two separate
> > domains ? And when you talk about being logged in, are yu controlling
> > access or just validating that someone is logged in or not, i.e. being
> > able to access information based on a user id.
> >
> > - Jason
> > [show/hide original text]
> > On Sun, Dec 2, 2018, at 10:04 AM, Ruben Reusser wrote: > hi there, > > I
> > have been trying to do the following: 1 apache http server, 2 sling >
> > instances. /tenant1 goes to sling instance number 1, tenant 2 goes to >
> > sling instance number 2. If I log in I'd love to be logged in to all >
> > sling instances, preferably not with a cookie for each tenant. Would >
> > love to hear suggestions in what direction I should concentrate my >
> > effort to achieve my goal here! > > thank you > > Ruben >
> >
>