Hi All, I have added the reviewed new approach as a comment to the Github issue. [1]
[1] https://github.com/wso2/product-microgateway/issues/298 Thanks, Sampath On Wed, Feb 27, 2019 at 1:39 PM Nuwan Dias <nuw...@wso2.com> wrote: > > > On Wed, Feb 27, 2019 at 12:54 PM Vanjikumaran Sivajothy <va...@wso2.com> > wrote: > >> OAuth Token can be exchanged for a JWT token; In that case, if the root >> OAuth token revoked there is a need of removing the relevant JWT token >> also. >> > > I'm not sure whether we support a scenario like that today. What is the > grant type that allows you to exchange an OAuth token for a self contained > (JWT) token? > >> >> Will it be under consideration in this implementation? >> >> On Wed, Feb 13, 2019 at 12:52 AM Nuwan Dias <nuw...@wso2.com> wrote: >> >>> >>> >>> 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 >>> >> >> >> -- >> *1G* >> _______________________________________________ >> 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 > -- *Sampath Rajapakse* | Software Engineer | WSO2 Inc. +94717313761 | samp...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
