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
