Hi Dinusha, True. I believe it should be a deployment recommendation. To be correct, it is not cache timeout at IdP, but it should be the recommended session timeout at IdP. IMO, I don't think it is a problem that we need to solve.
thanks, Dimuthu On Tue, Feb 23, 2016 at 6:36 PM, Dinusha Senanayaka <[email protected]> wrote: > Hi Dimuthu, > > On Tue, Feb 23, 2016 at 5:27 PM, Dimuthu Leelarathne <[email protected]> > wrote: > >> Hi Dinusha, >> >> Why don't we use the custom cache expiry time at the IdP as well? I >> believe it is a better solution than doing a ping to keep the IdP session >> live. >> > > With the current AppM architecture, we don't have key-manager like feature > that could install and use between gateway and IdP communication. It's > direct web service calls to IdP, where AppM don't have control over IdP > cache. > > >> >> thanks, >> Dimuthu >> >> On Tue, Feb 2, 2016 at 4:52 PM, Dinusha Senanayaka <[email protected]> >> wrote: >> >>> 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 >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Director >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile : 0773661935 >> >> Lean . Enterprise . Middleware >> > > > > -- > Dinusha Dilrukshi > Associate Technical Lead > WSO2 Inc.: http://wso2.com/ > Mobile: +94725255071 > Blog: http://dinushasblog.blogspot.com/ > -- Dimuthu Leelarathne Director WSO2, Inc. (http://wso2.com) email: [email protected] Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
