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/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to