Yes, Nuwan. We will add a configurable cache timeout + expired based on last access (not based on the initial value added time to cache).
+1 for RuwanA purposed model. This need another config to keep the IdP ping interval. Regards, Dinusha. On Tue, Feb 2, 2016 at 4:38 PM, Nuwan Dias <[email protected]> wrote: > Some things to consider with this is that the cache timeout is no longer > (necessarily) restricted to 15 minutes. Its configurable. And being a > Gateway product, I feel that people will want extended cache timeouts for > better performance. It has been so for the API Gateway. > > Thanks, > NuwanD. > > On Tue, Feb 2, 2016 at 4:28 PM, Ruwan Abeykoon <[email protected]> wrote: > >> Hi All, >> Can we implement the following strategy in the gateway, >> 1. Upon first application request, the GW consult with IdP and cache the >> IdP response if authenticated ( this is the current behaviour). However >> cache object needs a change. Figure 1. >> 2. Any subsequent application hit on the gateway, we check the last time >> IdP is consulted. If this is less than 7 min (Half of the IdP session >> Timeout) we consult IdP again as in step 1, and update the cache >> accordingly. >> >> This way, we can keep IdP session active as long as the GW session is >> active and requests keep arriving. The security issues will not arise as GW >> consult IdP occasionally but regularly. So if a user is disabled in IdP, >> that information is cascaded to the gateway within 7 min. We will not need >> any background polling mechanism in this way, and only activated when users >> are actively using the GW. >> >> The only change needed to be done is at the >> gateway SAML2AuthenticationHandler. >> >> [image: Inline image 2] >> >> >> Figure 1 >> >> On Tue, Feb 2, 2016 at 3:50 PM, Dinusha Senanayaka <[email protected]> >> wrote: >> >>> Hi All, >>> >>> *How do we handle authenticated user session currently* >>> >>> We use Hazelcast cache in the gateway and once user first authenticated >>> from the IdP, we create a new cookie and put it to this cache. Then all >>> other web app access requests are served from gateway cache until it get >>> expired, without calling IdP for each page load. >>> >>> *Issue with above model* >>> >>> We have used default CacheManager to initialize above mentioned cache >>> which has 15 min of expiry time. By default IdP session also set to 15 min. >>> Even though user actively accessing the app till the 15 min, IdP will see >>> him as a idle user since request are not going to IdP and served from the >>> gateway cache. Hence, both GW cache and IdP session get cleared at after >>> 15min and user get redirect to login page. >>> >>> *Solution* >>> >>> As per the discussion had with Dulanja, instead of using default cache >>> manager, we could initial a cache manager which expired based on last >>> access time. Refer thread [1]. So that gateway cache (session) will be >>> active as long as user accessing the web app. But IdP will get timeout >>> which won't be an issue to access the app. But can this cause security >>> threat since cache won't get expired as long as user is active ? >>> >>> [1]. [Dev] Set a desired value to HazelCast Cache Timeout >>> >>> Regards, >>> Dinusha. >>> >>> -- >>> Dinusha Dilrukshi >>> Associate Technical Lead >>> WSO2 Inc.: http://wso2.com/ >>> Mobile: +94725255071 >>> Blog: http://dinushasblog.blogspot.com/ >>> >> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Architect,* >> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >> *lean.enterprise.middleware.* >> >> email: [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- Dinusha Dilrukshi Associate Technical Lead WSO2 Inc.: http://wso2.com/ Mobile: +94725255071 Blog: http://dinushasblog.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
