I think this approach is better than pub/sub topic because in that case when new gateway joins cluster it cannot get all updates at first time. OAuth token to JWT token exchange not available today. What available is requesting access token with openID scope. In that case we will issue access token and ID token(same as JWT token) both. In that case i do not think we have JTI in token body. If we take persistence logic then JTI stored in same way we store token. So revoke token means revoke JTI eventually.
Thanks, sanjeewa. 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 > -- *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
