Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Prabath Siriwardana]

Yes - this is something we should closely look at... this is not just for
token revocation but for any security critical event...

Thanks & regards,
-Prabath

On Mon, Oct 3, 2016 at 1:19 AM, Ishara Karunarathna 
wrote:

> Hi All,
>
> There is a OpenID RISC (Risk and Incident Sharing and Coordination) WG [1]
> they also talking about Share information about important security events.
> They also looking for Pub sub model for Oauth token revocation, OIDC
> session revocation etc[2].
>
> I think If there is a broker capable of supporting our requirement no
> wrong if we try this.
>
> Thanks,
> Ishara
>
> [1] http://openid.net/wg/risc/
> [2] http://lists.openid.net/pipermail/openid-specs-risc/
> Week-of-Mon-20151102/61.html
>
> On Mon, Oct 3, 2016 at 12:17 PM, Dimuthu Leelarathne 
> wrote:
>
>> Hi Sanjeewa,
>>
>> On Mon, Oct 3, 2016 at 10:33 AM, Sanjeewa Malalgoda 
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
>>> wrote:
>>>


 On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda  wrote:

> Hi,
> Before we need to take any decision about moving to pub/sub approach
> we need to consider some of the facts.
>
> As of now token revoke responses carrying revoke token as transport
> header and at gateway cache clear handler will remove revoked token from
> cache. Then it will replicate to other nodes through clustering.
>
> If we are planning to have pub/sub solution then either oauth2
> implementation or cache clear handler at gateway should push this event to
> topic.
> Both cases we need to maintain message broker in gateway or key
> manager while all gateway workers subscribe to topic available there.
> Then we need to think about how high availability works for this
> broker(since we have multiple gateways and key managers in most of the
> deployments). IMHO it will add more complexity to deployment.
>
> My main point is even if we use pub/sub in order to achieve HA we need
> multiple broker instances. Then those need to synchup with each other and
> we need some sort of group communication for that(again clustering comes 
> to
> picture).
>
> May be we can evaluate some solution like kafka for this. We are
> evaluating it for traffic manager update retrieving process(through kafka
> event publisher in CEP and extension to subscribe topics to fetch 
> updates).
> It will not be a first class support but through extensions we may be able
> to do that. Even with that we need to maintain zoo-keeper cluster when we
> have multiple brokers(again this make deployment bit complicate).
>

 What if we add this as an deployment option? We can ship it as a
 component that is switched on with configs.

>>> I'm sorry if i didn't make it clear in my first reply. What i wanted to
>>> tell is even if we remove hazlecast based clustering we still need
>>> something like zookeeper which does cluster coordination for traffic
>>> managers.  So we cannot completely eliminate clustering from deployment.
>>>
>>
>> Clustering traffic managers are ok. The problem is clustering gateways.
>> Clustering gateways hinders our ability to scale to large numbers. Since
>> the gateway t-manager ration is 10 to 1, it is ok to cluster t-managers.
>>
>> thanks,
>> Dimuthu
>>
>>
>>> Thanks,
>>> sanjeewa.
>>>


>
> If need we can wait 15 minutes for cache timeout rather adding this
> kind of feature if users do not like to use gateway clustering.
>
> And clustering is required to replicate validation information cache
> across gateway nodes. Otherwise when LB not routing requests without
> session awareness gateways may do same key validation call again and 
> again.
> In this case usually cluster communication is cheaper than another key
> validation call. So if we remove clustering completely then we need to
> think about this as well.
>

 I think the best here is switching on IP hashing at LB.

 Cos think of a case where we have to support a large TPS. Having this
 would be so easy. For large TPS (say .. X TPS range) they wouldn't even
 mind having a their own broker in HA.

 thanks,
 Dimuthu



>
> Thanks,
> sanjeewa.
>
>
>
> On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne <
> dimut...@wso2.com> wrote:
>
>> Hi,
>>
>> If we publish OAuth key revocation to a topic (we can do so using by
>> writing an extension to WSO2IS), we can remove clustering in the APIM
>> gateway. Are there better ways for achieving the same? Can we prioratise
>> this for next APIM release?
>>
>> thanks,
>> Dimuthu
>>
>> --
>> Dimuthu Leelarathne
>> Director, Solutions Architecture
>>

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Ishara Karunarathna]

Hi All,

There is a OpenID RISC (Risk and Incident Sharing and Coordination) WG [1]
they also talking about Share information about important security events.
They also looking for Pub sub model for Oauth token revocation, OIDC
session revocation etc[2].

I think If there is a broker capable of supporting our requirement no wrong
if we try this.

Thanks,
Ishara

[1] http://openid.net/wg/risc/
[2]
http://lists.openid.net/pipermail/openid-specs-risc/Week-of-Mon-20151102/61.html

On Mon, Oct 3, 2016 at 12:17 PM, Dimuthu Leelarathne 
wrote:

> Hi Sanjeewa,
>
> On Mon, Oct 3, 2016 at 10:33 AM, Sanjeewa Malalgoda 
> wrote:
>
>>
>>
>> On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 Hi,
 Before we need to take any decision about moving to pub/sub approach we
 need to consider some of the facts.

 As of now token revoke responses carrying revoke token as transport
 header and at gateway cache clear handler will remove revoked token from
 cache. Then it will replicate to other nodes through clustering.

 If we are planning to have pub/sub solution then either oauth2
 implementation or cache clear handler at gateway should push this event to
 topic.
 Both cases we need to maintain message broker in gateway or key manager
 while all gateway workers subscribe to topic available there.
 Then we need to think about how high availability works for this
 broker(since we have multiple gateways and key managers in most of the
 deployments). IMHO it will add more complexity to deployment.

 My main point is even if we use pub/sub in order to achieve HA we need
 multiple broker instances. Then those need to synchup with each other and
 we need some sort of group communication for that(again clustering comes to
 picture).

 May be we can evaluate some solution like kafka for this. We are
 evaluating it for traffic manager update retrieving process(through kafka
 event publisher in CEP and extension to subscribe topics to fetch updates).
 It will not be a first class support but through extensions we may be able
 to do that. Even with that we need to maintain zoo-keeper cluster when we
 have multiple brokers(again this make deployment bit complicate).

>>>
>>> What if we add this as an deployment option? We can ship it as a
>>> component that is switched on with configs.
>>>
>> I'm sorry if i didn't make it clear in my first reply. What i wanted to
>> tell is even if we remove hazlecast based clustering we still need
>> something like zookeeper which does cluster coordination for traffic
>> managers.  So we cannot completely eliminate clustering from deployment.
>>
>
> Clustering traffic managers are ok. The problem is clustering gateways.
> Clustering gateways hinders our ability to scale to large numbers. Since
> the gateway t-manager ration is 10 to 1, it is ok to cluster t-managers.
>
> thanks,
> Dimuthu
>
>
>> Thanks,
>> sanjeewa.
>>
>>>
>>>

 If need we can wait 15 minutes for cache timeout rather adding this
 kind of feature if users do not like to use gateway clustering.

 And clustering is required to replicate validation information cache
 across gateway nodes. Otherwise when LB not routing requests without
 session awareness gateways may do same key validation call again and again.
 In this case usually cluster communication is cheaper than another key
 validation call. So if we remove clustering completely then we need to
 think about this as well.

>>>
>>> I think the best here is switching on IP hashing at LB.
>>>
>>> Cos think of a case where we have to support a large TPS. Having this
>>> would be so easy. For large TPS (say .. X TPS range) they wouldn't even
>>> mind having a their own broker in HA.
>>>
>>> thanks,
>>> Dimuthu
>>>
>>>
>>>

 Thanks,
 sanjeewa.



 On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne <
 dimut...@wso2.com> wrote:

> Hi,
>
> If we publish OAuth key revocation to a topic (we can do so using by
> writing an extension to WSO2IS), we can remove clustering in the APIM
> gateway. Are there better ways for achieving the same? Can we prioratise
> this for next APIM release?
>
> thanks,
> Dimuthu
>
> --
> Dimuthu Leelarathne
> Director, Solutions Architecture
>
> WSO2, Inc. (http://wso2.com)
> email: dimut...@wso2.com
> Mobile: +94773661935
> Blog: http://muthulee.blogspot.com
>
> Lean . Enterprise . Middleware
>



 --

 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94713068779

 blog
 :http://sanjeewamalalgoda.blogspot.com/
 

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Dimuthu Leelarathne]

Hi Sanjeewa,

On Mon, Oct 3, 2016 at 10:33 AM, Sanjeewa Malalgoda 
wrote:

>
>
> On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
> wrote:
>
>>
>>
>> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Hi,
>>> Before we need to take any decision about moving to pub/sub approach we
>>> need to consider some of the facts.
>>>
>>> As of now token revoke responses carrying revoke token as transport
>>> header and at gateway cache clear handler will remove revoked token from
>>> cache. Then it will replicate to other nodes through clustering.
>>>
>>> If we are planning to have pub/sub solution then either oauth2
>>> implementation or cache clear handler at gateway should push this event to
>>> topic.
>>> Both cases we need to maintain message broker in gateway or key manager
>>> while all gateway workers subscribe to topic available there.
>>> Then we need to think about how high availability works for this
>>> broker(since we have multiple gateways and key managers in most of the
>>> deployments). IMHO it will add more complexity to deployment.
>>>
>>> My main point is even if we use pub/sub in order to achieve HA we need
>>> multiple broker instances. Then those need to synchup with each other and
>>> we need some sort of group communication for that(again clustering comes to
>>> picture).
>>>
>>> May be we can evaluate some solution like kafka for this. We are
>>> evaluating it for traffic manager update retrieving process(through kafka
>>> event publisher in CEP and extension to subscribe topics to fetch updates).
>>> It will not be a first class support but through extensions we may be able
>>> to do that. Even with that we need to maintain zoo-keeper cluster when we
>>> have multiple brokers(again this make deployment bit complicate).
>>>
>>
>> What if we add this as an deployment option? We can ship it as a
>> component that is switched on with configs.
>>
> I'm sorry if i didn't make it clear in my first reply. What i wanted to
> tell is even if we remove hazlecast based clustering we still need
> something like zookeeper which does cluster coordination for traffic
> managers.  So we cannot completely eliminate clustering from deployment.
>

Clustering traffic managers are ok. The problem is clustering gateways.
Clustering gateways hinders our ability to scale to large numbers. Since
the gateway t-manager ration is 10 to 1, it is ok to cluster t-managers.

thanks,
Dimuthu


> Thanks,
> sanjeewa.
>
>>
>>
>>>
>>> If need we can wait 15 minutes for cache timeout rather adding this kind
>>> of feature if users do not like to use gateway clustering.
>>>
>>> And clustering is required to replicate validation information cache
>>> across gateway nodes. Otherwise when LB not routing requests without
>>> session awareness gateways may do same key validation call again and again.
>>> In this case usually cluster communication is cheaper than another key
>>> validation call. So if we remove clustering completely then we need to
>>> think about this as well.
>>>
>>
>> I think the best here is switching on IP hashing at LB.
>>
>> Cos think of a case where we have to support a large TPS. Having this
>> would be so easy. For large TPS (say .. X TPS range) they wouldn't even
>> mind having a their own broker in HA.
>>
>> thanks,
>> Dimuthu
>>
>>
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne >> > wrote:
>>>
 Hi,

 If we publish OAuth key revocation to a topic (we can do so using by
 writing an extension to WSO2IS), we can remove clustering in the APIM
 gateway. Are there better ways for achieving the same? Can we prioratise
 this for next APIM release?

 thanks,
 Dimuthu

 --
 Dimuthu Leelarathne
 Director, Solutions Architecture

 WSO2, Inc. (http://wso2.com)
 email: dimut...@wso2.com
 Mobile: +94773661935
 Blog: http://muthulee.blogspot.com

 Lean . Enterprise . Middleware

>>>
>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Director, Solutions Architecture
>>
>> WSO2, Inc. (http://wso2.com)
>> email: dimut...@wso2.com
>> Mobile: +94773661935
>> Blog: http://muthulee.blogspot.com
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>


-- 
Dimuthu Leelarathne
Director, Solutions Architecture

WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile: +94773661935
Blog: http://muthulee.blogspot.com

Lean . Enterprise . Middleware

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Sanjeewa Malalgoda]

On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
wrote:

>
>
> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi,
>> Before we need to take any decision about moving to pub/sub approach we
>> need to consider some of the facts.
>>
>> As of now token revoke responses carrying revoke token as transport
>> header and at gateway cache clear handler will remove revoked token from
>> cache. Then it will replicate to other nodes through clustering.
>>
>> If we are planning to have pub/sub solution then either oauth2
>> implementation or cache clear handler at gateway should push this event to
>> topic.
>> Both cases we need to maintain message broker in gateway or key manager
>> while all gateway workers subscribe to topic available there.
>> Then we need to think about how high availability works for this
>> broker(since we have multiple gateways and key managers in most of the
>> deployments). IMHO it will add more complexity to deployment.
>>
>> My main point is even if we use pub/sub in order to achieve HA we need
>> multiple broker instances. Then those need to synchup with each other and
>> we need some sort of group communication for that(again clustering comes to
>> picture).
>>
>> May be we can evaluate some solution like kafka for this. We are
>> evaluating it for traffic manager update retrieving process(through kafka
>> event publisher in CEP and extension to subscribe topics to fetch updates).
>> It will not be a first class support but through extensions we may be able
>> to do that. Even with that we need to maintain zoo-keeper cluster when we
>> have multiple brokers(again this make deployment bit complicate).
>>
>
> What if we add this as an deployment option? We can ship it as a component
> that is switched on with configs.
>
I'm sorry if i didn't make it clear in my first reply. What i wanted to
tell is even if we remove hazlecast based clustering we still need
something like zookeeper which does cluster coordination for traffic
managers.  So we cannot completely eliminate clustering from deployment.

Thanks,
sanjeewa.

>
>
>>
>> If need we can wait 15 minutes for cache timeout rather adding this kind
>> of feature if users do not like to use gateway clustering.
>>
>> And clustering is required to replicate validation information cache
>> across gateway nodes. Otherwise when LB not routing requests without
>> session awareness gateways may do same key validation call again and again.
>> In this case usually cluster communication is cheaper than another key
>> validation call. So if we remove clustering completely then we need to
>> think about this as well.
>>
>
> I think the best here is switching on IP hashing at LB.
>
> Cos think of a case where we have to support a large TPS. Having this
> would be so easy. For large TPS (say .. X TPS range) they wouldn't even
> mind having a their own broker in HA.
>
> thanks,
> Dimuthu
>
>
>
>>
>> Thanks,
>> sanjeewa.
>>
>>
>>
>> On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne 
>> wrote:
>>
>>> Hi,
>>>
>>> If we publish OAuth key revocation to a topic (we can do so using by
>>> writing an extension to WSO2IS), we can remove clustering in the APIM
>>> gateway. Are there better ways for achieving the same? Can we prioratise
>>> this for next APIM release?
>>>
>>> thanks,
>>> Dimuthu
>>>
>>> --
>>> Dimuthu Leelarathne
>>> Director, Solutions Architecture
>>>
>>> WSO2, Inc. (http://wso2.com)
>>> email: dimut...@wso2.com
>>> Mobile: +94773661935
>>> Blog: http://muthulee.blogspot.com
>>>
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>
>
> --
> Dimuthu Leelarathne
> Director, Solutions Architecture
>
> WSO2, Inc. (http://wso2.com)
> email: dimut...@wso2.com
> Mobile: +94773661935
> Blog: http://muthulee.blogspot.com
>
> Lean . Enterprise . Middleware
>



-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Dimuthu Leelarathne]

On Mon, Oct 3, 2016 at 9:52 AM, Nuwan Dias  wrote:

>
>
> On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
> wrote:
>
>>
>>
>> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Hi,
>>> Before we need to take any decision about moving to pub/sub approach we
>>> need to consider some of the facts.
>>>
>>> As of now token revoke responses carrying revoke token as transport
>>> header and at gateway cache clear handler will remove revoked token from
>>> cache. Then it will replicate to other nodes through clustering.
>>>
>>> If we are planning to have pub/sub solution then either oauth2
>>> implementation or cache clear handler at gateway should push this event to
>>> topic.
>>> Both cases we need to maintain message broker in gateway or key manager
>>> while all gateway workers subscribe to topic available there.
>>> Then we need to think about how high availability works for this
>>> broker(since we have multiple gateways and key managers in most of the
>>> deployments). IMHO it will add more complexity to deployment.
>>>
>>> My main point is even if we use pub/sub in order to achieve HA we need
>>> multiple broker instances. Then those need to synchup with each other and
>>> we need some sort of group communication for that(again clustering comes to
>>> picture).
>>>
>>> May be we can evaluate some solution like kafka for this. We are
>>> evaluating it for traffic manager update retrieving process(through kafka
>>> event publisher in CEP and extension to subscribe topics to fetch updates).
>>> It will not be a first class support but through extensions we may be able
>>> to do that. Even with that we need to maintain zoo-keeper cluster when we
>>> have multiple brokers(again this make deployment bit complicate).
>>>
>>
>> What if we add this as an deployment option? We can ship it as a
>> component that is switched on with configs.
>>
>
> No more deployment options please :D. We're having enough complications
> with the existing patterns. If we're doing this we should do it and
> recommend that only. Having too many options complicates the code base and
> the customer experiences as well.
>

IMO we should cut down the existing ones, and we can. We should not keep
things for historic reasons. But whenever we can get a huge gain, we should
add it.

thanks,
Dimuthu

>
>>
>>>
>>> If need we can wait 15 minutes for cache timeout rather adding this kind
>>> of feature if users do not like to use gateway clustering.
>>>
>>> And clustering is required to replicate validation information cache
>>> across gateway nodes. Otherwise when LB not routing requests without
>>> session awareness gateways may do same key validation call again and again.
>>> In this case usually cluster communication is cheaper than another key
>>> validation call. So if we remove clustering completely then we need to
>>> think about this as well.
>>>
>>
>> I think the best here is switching on IP hashing at LB.
>>
>> Cos think of a case where we have to support a large TPS. Having this
>> would be so easy. For large TPS (say .. X TPS range) they wouldn't even
>> mind having a their own broker in HA.
>>
>> thanks,
>> Dimuthu
>>
>>
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne >> > wrote:
>>>
 Hi,

 If we publish OAuth key revocation to a topic (we can do so using by
 writing an extension to WSO2IS), we can remove clustering in the APIM
 gateway. Are there better ways for achieving the same? Can we prioratise
 this for next APIM release?

 thanks,
 Dimuthu

 --
 Dimuthu Leelarathne
 Director, Solutions Architecture

 WSO2, Inc. (http://wso2.com)
 email: dimut...@wso2.com
 Mobile: +94773661935
 Blog: http://muthulee.blogspot.com

 Lean . Enterprise . Middleware

>>>
>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Director, Solutions Architecture
>>
>> WSO2, Inc. (http://wso2.com)
>> email: dimut...@wso2.com
>> Mobile: +94773661935
>> Blog: http://muthulee.blogspot.com
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>



-- 
Dimuthu Leelarathne
Director, Solutions Architecture

WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile: +94773661935
Blog: http://muthulee.blogspot.com

Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Nuwan Dias]

On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne 
wrote:

>
>
> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi,
>> Before we need to take any decision about moving to pub/sub approach we
>> need to consider some of the facts.
>>
>> As of now token revoke responses carrying revoke token as transport
>> header and at gateway cache clear handler will remove revoked token from
>> cache. Then it will replicate to other nodes through clustering.
>>
>> If we are planning to have pub/sub solution then either oauth2
>> implementation or cache clear handler at gateway should push this event to
>> topic.
>> Both cases we need to maintain message broker in gateway or key manager
>> while all gateway workers subscribe to topic available there.
>> Then we need to think about how high availability works for this
>> broker(since we have multiple gateways and key managers in most of the
>> deployments). IMHO it will add more complexity to deployment.
>>
>> My main point is even if we use pub/sub in order to achieve HA we need
>> multiple broker instances. Then those need to synchup with each other and
>> we need some sort of group communication for that(again clustering comes to
>> picture).
>>
>> May be we can evaluate some solution like kafka for this. We are
>> evaluating it for traffic manager update retrieving process(through kafka
>> event publisher in CEP and extension to subscribe topics to fetch updates).
>> It will not be a first class support but through extensions we may be able
>> to do that. Even with that we need to maintain zoo-keeper cluster when we
>> have multiple brokers(again this make deployment bit complicate).
>>
>
> What if we add this as an deployment option? We can ship it as a component
> that is switched on with configs.
>

No more deployment options please :D. We're having enough complications
with the existing patterns. If we're doing this we should do it and
recommend that only. Having too many options complicates the code base and
the customer experiences as well.

>
>
>>
>> If need we can wait 15 minutes for cache timeout rather adding this kind
>> of feature if users do not like to use gateway clustering.
>>
>> And clustering is required to replicate validation information cache
>> across gateway nodes. Otherwise when LB not routing requests without
>> session awareness gateways may do same key validation call again and again.
>> In this case usually cluster communication is cheaper than another key
>> validation call. So if we remove clustering completely then we need to
>> think about this as well.
>>
>
> I think the best here is switching on IP hashing at LB.
>
> Cos think of a case where we have to support a large TPS. Having this
> would be so easy. For large TPS (say .. X TPS range) they wouldn't even
> mind having a their own broker in HA.
>
> thanks,
> Dimuthu
>
>
>
>>
>> Thanks,
>> sanjeewa.
>>
>>
>>
>> On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne 
>> wrote:
>>
>>> Hi,
>>>
>>> If we publish OAuth key revocation to a topic (we can do so using by
>>> writing an extension to WSO2IS), we can remove clustering in the APIM
>>> gateway. Are there better ways for achieving the same? Can we prioratise
>>> this for next APIM release?
>>>
>>> thanks,
>>> Dimuthu
>>>
>>> --
>>> Dimuthu Leelarathne
>>> Director, Solutions Architecture
>>>
>>> WSO2, Inc. (http://wso2.com)
>>> email: dimut...@wso2.com
>>> Mobile: +94773661935
>>> Blog: http://muthulee.blogspot.com
>>>
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>
>
> --
> Dimuthu Leelarathne
> Director, Solutions Architecture
>
> WSO2, Inc. (http://wso2.com)
> email: dimut...@wso2.com
> Mobile: +94773661935
> Blog: http://muthulee.blogspot.com
>
> Lean . Enterprise . Middleware
>



-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Dimuthu Leelarathne]

On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda 
wrote:

> Hi,
> Before we need to take any decision about moving to pub/sub approach we
> need to consider some of the facts.
>
> As of now token revoke responses carrying revoke token as transport header
> and at gateway cache clear handler will remove revoked token from cache.
> Then it will replicate to other nodes through clustering.
>
> If we are planning to have pub/sub solution then either oauth2
> implementation or cache clear handler at gateway should push this event to
> topic.
> Both cases we need to maintain message broker in gateway or key manager
> while all gateway workers subscribe to topic available there.
> Then we need to think about how high availability works for this
> broker(since we have multiple gateways and key managers in most of the
> deployments). IMHO it will add more complexity to deployment.
>
> My main point is even if we use pub/sub in order to achieve HA we need
> multiple broker instances. Then those need to synchup with each other and
> we need some sort of group communication for that(again clustering comes to
> picture).
>
> May be we can evaluate some solution like kafka for this. We are
> evaluating it for traffic manager update retrieving process(through kafka
> event publisher in CEP and extension to subscribe topics to fetch updates).
> It will not be a first class support but through extensions we may be able
> to do that. Even with that we need to maintain zoo-keeper cluster when we
> have multiple brokers(again this make deployment bit complicate).
>

What if we add this as an deployment option? We can ship it as a component
that is switched on with configs.


>
> If need we can wait 15 minutes for cache timeout rather adding this kind
> of feature if users do not like to use gateway clustering.
>
> And clustering is required to replicate validation information cache
> across gateway nodes. Otherwise when LB not routing requests without
> session awareness gateways may do same key validation call again and again.
> In this case usually cluster communication is cheaper than another key
> validation call. So if we remove clustering completely then we need to
> think about this as well.
>

I think the best here is switching on IP hashing at LB.

Cos think of a case where we have to support a large TPS. Having this would
be so easy. For large TPS (say .. X TPS range) they wouldn't even mind
having a their own broker in HA.

thanks,
Dimuthu



>
> Thanks,
> sanjeewa.
>
>
>
> On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne 
> wrote:
>
>> Hi,
>>
>> If we publish OAuth key revocation to a topic (we can do so using by
>> writing an extension to WSO2IS), we can remove clustering in the APIM
>> gateway. Are there better ways for achieving the same? Can we prioratise
>> this for next APIM release?
>>
>> thanks,
>> Dimuthu
>>
>> --
>> Dimuthu Leelarathne
>> Director, Solutions Architecture
>>
>> WSO2, Inc. (http://wso2.com)
>> email: dimut...@wso2.com
>> Mobile: +94773661935
>> Blog: http://muthulee.blogspot.com
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>


-- 
Dimuthu Leelarathne
Director, Solutions Architecture

WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile: +94773661935
Blog: http://muthulee.blogspot.com

Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Bhathiya Jayasekara]

Hi Dimuthu,

On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne 
wrote:

> Hi,
>
> If we publish OAuth key revocation to a topic (we can do so using by
> writing an extension to WSO2IS), we can remove clustering in the APIM
> gateway.
>

What is the reason for doing this? Is this just a part of effort we are
putting to get rid of hazelcast, or are there any other reasons?

Thanks,
Bhathiya

-- 
*Bhathiya Jayasekara*
*Senior Software Engineer,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185 <%2B94715478185>*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Pub/sub pattern for OAuth Key Revocations

[Sanjeewa Malalgoda]

Hi,
Before we need to take any decision about moving to pub/sub approach we
need to consider some of the facts.

As of now token revoke responses carrying revoke token as transport header
and at gateway cache clear handler will remove revoked token from cache.
Then it will replicate to other nodes through clustering.

If we are planning to have pub/sub solution then either oauth2
implementation or cache clear handler at gateway should push this event to
topic.
Both cases we need to maintain message broker in gateway or key manager
while all gateway workers subscribe to topic available there.
Then we need to think about how high availability works for this
broker(since we have multiple gateways and key managers in most of the
deployments). IMHO it will add more complexity to deployment.

My main point is even if we use pub/sub in order to achieve HA we need
multiple broker instances. Then those need to synchup with each other and
we need some sort of group communication for that(again clustering comes to
picture).

May be we can evaluate some solution like kafka for this. We are evaluating
it for traffic manager update retrieving process(through kafka event
publisher in CEP and extension to subscribe topics to fetch updates). It
will not be a first class support but through extensions we may be able to
do that. Even with that we need to maintain zoo-keeper cluster when we have
multiple brokers(again this make deployment bit complicate).

If need we can wait 15 minutes for cache timeout rather adding this kind of
feature if users do not like to use gateway clustering.

And clustering is required to replicate validation information cache across
gateway nodes. Otherwise when LB not routing requests without session
awareness gateways may do same key validation call again and again. In this
case usually cluster communication is cheaper than another key validation
call. So if we remove clustering completely then we need to think about
this as well.

Thanks,
sanjeewa.



On Tue, Sep 27, 2016 at 11:31 AM, Dimuthu Leelarathne 
wrote:

> Hi,
>
> If we publish OAuth key revocation to a topic (we can do so using by
> writing an extension to WSO2IS), we can remove clustering in the APIM
> gateway. Are there better ways for achieving the same? Can we prioratise
> this for next APIM release?
>
> thanks,
> Dimuthu
>
> --
> Dimuthu Leelarathne
> Director, Solutions Architecture
>
> WSO2, Inc. (http://wso2.com)
> email: dimut...@wso2.com
> Mobile: +94773661935
> Blog: http://muthulee.blogspot.com
>
> Lean . Enterprise . Middleware
>



-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture