Thanks for the inputs. When i think about this feature further i think we do not need to limit this capability for JWT revoke. We can implement some mechanism to send some updates details etc to gateways from outside on demand. JWT revocation could be one use case. But we need to check the feasibility of pushing config updates(API resource updates etc), blocking conditions etc. If we have something like config API then it will also work here. If we have high decentralized system with multiple gateways then updating each of them might be complicated task( However this might be easy if container management system).
Thanks, sanjeewa. On Tue, Feb 12, 2019 at 5:11 PM Nuwan Dias <[email protected]> wrote: > I have created a Git issue for this [1]. > > I believe the pub-sub model is more suitable for this. I've explained the > proposed architecture on the Git issue. > > This capability is only required for the ones who want to propagate token > revocations to the microgateways as soon as possible. The tokens (usually) > expire in about an hour. Therefore the user group who are interested in > this feature are the ones who would typically want the revocations to be > propagated sooner than that. And these types of users would most probably > demand for a near real time impact. The disadvantage of the pull model is > that for the revocations to be notified soon enough, the microgateways will > have to keep polling the STS quite frequently, say like once every minute > at least. With 100 microgateways, that would mean a considerable amount of > load on the STS to deal with. And we now have to worry about the scaling > factor of the STS along with the scaling factor of the microgateway. Hence > I doubt the polling model is right for this. > > With web-hooks the problem is that the STS requires an outward connection > to each of the microgateways. Imagine having the STS on cloud and the > microgateways on-prem. The cloud would not have a physical connection to > the on-prem microgateways to revoke tokens. > > The pub-sub model gives us a decoupled architecture (in terms of > scalability) with a near real-time impact, which I think is ideal. For the > persistence related issue I think we need to introduce a lightweight > persistence layer across the microgateways. > > [1] - https://github.com/wso2/product-microgateway/issues/298 > > On Sat, Feb 9, 2019 at 9:53 PM Fazlan Nazeem <[email protected]> wrote: > >> Hi Sanjeewa, >> >> Irrespective of the method we use to implement this, once we choose a >> mechanism, we will not be able to refer to the JWT tokens as >> self-contained, isn't it? Because we will have to depend on an external >> party to decide the validity of a token. >> >> AFAIU, I think the pub/sub model and push model has a disadvantage if the >> process running the topic(in pub/sub model) or the microgateway(in push >> model) restarted(unless we repopulate the topic or the mgw memory on each >> restart with JTIs of unexpired revoked tokens). >> >> With the Pull model, I don't see this issue. the key manager only needs >> to store the unexpired revoked token information. >> >> I also feel that we need to introduce a config to switch on >> enabling/disabling this feature so that we can also use the microgateways >> in the current mode. >> >> On Thu, Feb 7, 2019 at 3:58 PM Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> Hi All, >>> I'm initiating this mail thread to discuss more about JWT token >>> revocation feature we are planning to implement for API Manager >>> micro-gateway. In API Manager micro-gateway we do support both oauth access >>> tokens and JWT access tokens. When we use OAuth access tokens we can revoke >>> them and make it effect immediately. Since all OAuth tokens geting >>> validated with key manager revoked tokens will fail validation. When we use >>> JWT token we do token validation within gateway itself without calling key >>> manager or external party. Since JWT is self contained one we are basically >>> trust its content as long as token not expired and signature valid. Then it >>> will be a problem. >>> >>> So we will need to have some mechanism to propagate revoked token >>> details to micro-gateways as well. Since self contained token revocation is >>> ineffective(there can be multiple token contents for same valid JTI due to >>> generated time and signature changes) most suitable way of doing this is >>> using JTI to identify revoked tokens. When JWT revoked we need to revoke it >>> using JTI. If we can send revoked JTI list to micro-gateway then we can >>> check that as part of key validation process. >>> >>> We need to find a way to send revoked JTI to microgateways, >>> Pub/sub model - all gateways need to subscribe to topic and get updated >>> about revoked tokens. >>> Pull Model - micro-gateways will call key manager or management server >>> and get update about revoked tokens >>> Push Model - Management server or key manager plugin will call all >>> deployed micro services and send revoked JWT list. >>> Each of these methods will have their own advantages and disadvantages. >>> Lets use this mail to discuss those in detail and come to conclusion. >>> >>> Thanks, >>> sanjeewa. >>> -- >>> *Sanjeewa Malalgoda* >>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>> (m) +94 712933253 | (e) [email protected] | (b) Blogger >>> <http://sanjeewamalalgoda.blogspot.com>, Medium >>> <https://medium.com/@sanjeewa190> >>> >>> GET INTEGRATION AGILE <https://wso2.com/signature> >>> Integration Agility for Digitally Driven Business >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> Thanks & Regards, >> >> *Fazlan Nazeem* >> Associate Technical Lead >> WSO2 Inc >> Mobile : +94772338839 >> [email protected] >> > > > -- > *Nuwan Dias* | Director | WSO2 Inc. > (m) +94 777 775 729 | (e) [email protected] > [image: Signature.jpg] > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Sanjeewa Malalgoda* Software Architect | Associate Director, Engineering - WSO2 Inc. (m) +94 712933253 | (e) [email protected] | (b) Blogger <http://sanjeewamalalgoda.blogspot.com>, Medium <https://medium.com/@sanjeewa190> GET INTEGRATION AGILE <https://wso2.com/signature> Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
