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 > >
