Added comment there. I think bringing broker and reliable key/value store both to address this complicate deployment and solutions.
Thanks, sanjeewa. On Thu, Feb 28, 2019 at 1:44 PM Sampath Rajapakshe <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> On Wed, Feb 27, 2019 at 12:54 PM Vanjikumaran Sivajothy <[email protected]> >> 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 <[email protected]> wrote: >>> >>>> >>>> >>>> On Wed, Feb 13, 2019 at 11:27 AM Sanjeewa Malalgoda <[email protected]> >>>> 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 <[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 >>>>> >>>> >>>> >>>> -- >>>> *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 >>>> >>> >>> >>> -- >>> *1G* >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> *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 >> > > > -- > > *Sampath Rajapakse* | Software Engineer | WSO2 Inc. > > +94717313761 | [email protected] > > > -- *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
