Hi Chamila, On Fri, Oct 4, 2019 at 12:28 PM Chamila Adhikarinayake <[email protected]> wrote:
> Hi > > I have a question regarding how this works on a distributed setup (say > Al-in-on Active-Active setup). If a revoke call is handled by one node, how > the other node's gateway gets this message? Does the keymanager node has to > publish the message to other node's topic when a revocation happens or > gateway listens to both KM nodes topics and gets a decision by evaluating > both topics? In both cases one node has to know all the other nodes (KM or > gateway) in the environment. wouldn't that be a problem in a container > environment? > Yes, in this case, each node has to publish the event to the other node as well. Each node can then listen to its own topic to get the revocation events irrespective of the node which received the revoke request. This is similar to how we publish throttle events to both nodes. If we are using service names instead of IPs, I guess there will not be an issue in containerized environments as well. > > On Fri, Oct 4, 2019 at 11:58 AM Bhathiya Jayasekara <[email protected]> > wrote: > >> Looks* good. >> >> On Fri, Oct 4, 2019 at 11:25 AM Fazlan Nazeem <[email protected]> wrote: >> >>> Hi all, >>> >>> We are working on supporting JWT revocation for synapse gateway. Please >>> note that the default token format for 3.0 synapse gateway is JWT. >>> >>> Please find the discussed design for this feature. >>> >>> [image: JWT.jpg] >>> >>> In summary, we will be storing the revoked token signatures against the >>> expiry timestamp(timestamp is needed for cleanup) in AM_DB and these >>> entries will be fetched to the gateway during the startup via a web app >>> deployed in KM. This is similar to how we fetch key templates and blocking >>> conditions during the startup via the throttle web app. >>> >>> When a token is being revoked after startup, an event will be put into a >>> JMS topic or multiple JMS topics depending on how the gateways are >>> subscribed to the topic(via JMS event publishers). When the JMS listener >>> fetches this event, it will clear the gateway cache entry related to the >>> token and also populate the in-memory revoke map. >>> >>> When a request is received to the gateway, it will be first validated >>> against the cache and only if it is not in the cache the signature will be >>> validated against the revoke map. We have decided not to validate against >>> the invalid cache for this flow because the revoke map will anyway have all >>> the invalid entries whereas the invalid cache will not always have all the >>> entries. >>> >>> Both the database table and revoke map has the expiry timestamp stored >>> in them to facilitate the cleanup process of expired revoked tokens. We are >>> planning to clean both the database table and the revoke map via a timer >>> task with a suitable interval to ensure they will not be growing >>> continuously. >>> >>> Please let me know your suggestions. >>> -- >>> Thanks & Regards, >>> >>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc >>> Mobile : +94772338839 | [email protected] >>> >>> >>> >> >> -- >> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc. >> (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com >> >> >> > > -- > Regards, > Chamila Adhikarinayake > Associate Technical Lead > WSO2, Inc. > Mobile - +94712346437 > Email - [email protected] > Blog - http://helpfromadhi.blogspot.com/ > -- Thanks & Regards, *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc Mobile : +94772338839 | [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
