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.
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
