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 <[email protected]> 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/000061.html > > On Mon, Oct 3, 2016 at 12:17 PM, Dimuthu Leelarathne <[email protected]> > wrote: > >> Hi Sanjeewa, >> >> On Mon, Oct 3, 2016 at 10:33 AM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Oct 3, 2016 at 9:33 AM, Dimuthu Leelarathne <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Sep 27, 2016 at 12:08 PM, Sanjeewa Malalgoda <[email protected] >>>> > 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 .. XXXXX 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 < >>>>> [email protected]> 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: [email protected] >>>>>> Mobile: +94773661935 >>>>>> Blog: http://muthulee.blogspot.com >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dimuthu Leelarathne >>>> Director, Solutions Architecture >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> Mobile: +94773661935 >>>> Blog: http://muthulee.blogspot.com >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Director, Solutions Architecture >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile: +94773661935 >> Blog: http://muthulee.blogspot.com >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Ishara Karunarathna > Associate Technical Lead > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: [email protected], blog: isharaaruna.blogspot.com, mobile: > +94717996791 > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
