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