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
