Re: [cas-user] CAS SLO, how does it terminate session on App if in a cluster environment?
Yan, I modified CAS-php files provided by vendor. 1. After ST is validated, app session id is written to redis with ST as key. 2. On logout, ST is used to get session id from redis (any host can do this). 3. Session id is sent to application's log out routine. For this to work, all hosts must use a common session store (database, redis, network file system) or somehow share the session. The application must regularly check the store for a valid session (vendor app does this for every page request). Ray On Thu, 2019-04-04 at 06:56 -0700, Yan Zhou wrote: Hi Ray, Can you elaborate on your approach when session is stored in Redis? You need the key to invalidate session in Redis, how does your CAS client know the Radis key? Is that the same as the app. session id? Thx! Yan On Tuesday, April 2, 2019 at 11:22:24 AM UTC-4, rbon wrote: Yan, We use two different approaches. Some apps have a common session store like redis. Other applications are configured to propagate the log out to all members of the cluster, but this is only practical for a small cluster. If your application runs in a container, maybe it can manage session replication (tomcat can do this). Another, maybe less desirable option, perhaps the load balancer can look for /logout and broadcast to all members of the cluster. Ray On Tue, 2019-04-02 at 07:53 -0700, Yan Zhou wrote: Hello! CAS4, for SLO, CAS server POSTs (back-channel SLO) to each service to perform SLO. It works because there is a CAS client in the application that intercepts such SLO requests, it can find the app. session Id based on the CAS service ticket Id. Is there any requirement on the part of Application to support SLO in a cluster environment? Our app. runs on multiple servers behind a load balancer, it uses CAS for authN. The problem, I run into, is that when App /logout endpoint gets called, it does not know where App Session is, the load balancer may direct the app /logout on the server not having the application session. Am I missing something? Thx! Yan -- Ray Bon Programmer analyst Development Services, University Systems 2507218831 | CLE 019 | rb...@uvic.ca -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/914f124b458bb130a60d3680ecd5846c743df451.camel%40uvic.ca.
Re: [cas-user] CAS SLO, how does it terminate session on App if in a cluster environment?
Hi Ray, Can you elaborate on your approach when session is stored in Redis? You need the key to invalidate session in Redis, how does your CAS client know the Radis key? Is that the same as the app. session id? Thx! Yan On Tuesday, April 2, 2019 at 11:22:24 AM UTC-4, rbon wrote: > > Yan, > > We use two different approaches. Some apps have a common session store > like redis. Other applications are configured to propagate the log out to > all members of the cluster, but this is only practical for a small cluster. > > If your application runs in a container, maybe it can manage session > replication (tomcat can do this). > Another, maybe less desirable option, perhaps the load balancer can look > for /logout and broadcast to all members of the cluster. > > Ray > > On Tue, 2019-04-02 at 07:53 -0700, Yan Zhou wrote: > > Hello! > > CAS4, for SLO, CAS server POSTs (back-channel SLO) to each service to > perform SLO. It works because there is a CAS client in the application > that intercepts such SLO requests, it can find the app. session Id based on > the CAS service ticket Id. > > Is there any requirement on the part of Application to support SLO in a > cluster environment? Our app. runs on multiple servers behind a load > balancer, it uses CAS for authN. > > The problem, I run into, is that when App /logout endpoint gets called, it > does not know where App Session is, the load balancer may direct the app > /logout on the server not having the application session. > > Am I missing something? > > Thx! > Yan > > -- > Ray Bon > Programmer analyst > Development Services, University Systems > 2507218831 | CLE 019 | rb...@uvic.ca > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/0aec37e4-f951-49c0-95ad-826808aa8789%40apereo.org.
Re: [cas-user] CAS SLO, how does it terminate session on App if in a cluster environment?
Yan, We use two different approaches. Some apps have a common session store like redis. Other applications are configured to propagate the log out to all members of the cluster, but this is only practical for a small cluster. If your application runs in a container, maybe it can manage session replication (tomcat can do this). Another, maybe less desirable option, perhaps the load balancer can look for /logout and broadcast to all members of the cluster. Ray On Tue, 2019-04-02 at 07:53 -0700, Yan Zhou wrote: Hello! CAS4, for SLO, CAS server POSTs (back-channel SLO) to each service to perform SLO. It works because there is a CAS client in the application that intercepts such SLO requests, it can find the app. session Id based on the CAS service ticket Id. Is there any requirement on the part of Application to support SLO in a cluster environment? Our app. runs on multiple servers behind a load balancer, it uses CAS for authN. The problem, I run into, is that when App /logout endpoint gets called, it does not know where App Session is, the load balancer may direct the app /logout on the server not having the application session. Am I missing something? Thx! Yan -- Ray Bon Programmer analyst Development Services, University Systems 2507218831 | CLE 019 | r...@uvic.ca -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1554218540.3128.24.camel%40uvic.ca.
[cas-user] CAS SLO, how does it terminate session on App if in a cluster environment?
Hello! CAS4, for SLO, CAS server POSTs (back-channel SLO) to each service to perform SLO. It works because there is a CAS client in the application that intercepts such SLO requests, it can find the app. session Id based on the CAS service ticket Id. Is there any requirement on the part of Application to support SLO in a cluster environment? Our app. runs on multiple servers behind a load balancer, it uses CAS for authN. The problem, I run into, is that when App /logout endpoint gets called, it does not know where App Session is, the load balancer may direct the app /logout on the server not having the application session. Am I missing something? Thx! Yan -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/75f6bf02-f72f-4683-80fd-82bb8984afe7%40apereo.org.
