On Wed, Feb 13, 2019 at 11:27 AM Sanjeewa Malalgoda <sanje...@wso2.com> wrote:
> 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). > Yes, once we have the infra setup we can use it for multiple things. > > Thanks, > sanjeewa. > > On Tue, Feb 12, 2019 at 5:11 PM Nuwan Dias <nuw...@wso2.com> 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 <fazl...@wso2.com> 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 <sanje...@wso2.com> >>> 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) sanje...@wso2.com | (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 >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Fazlan Nazeem* >>> Associate Technical Lead >>> WSO2 Inc >>> Mobile : +94772338839 >>> fazl...@wso2.com >>> >> >> >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) nuw...@wso2.com >> [image: Signature.jpg] >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Sanjeewa Malalgoda* > Software Architect | Associate Director, Engineering - WSO2 Inc. > (m) +94 712933253 | (e) sanje...@wso2.com | (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 > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) nuw...@wso2.com [image: Signature.jpg]
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
