@Hasintha Indrajee <hasin...@wso2.com> To properly address this, we have to bring the oauth event publisher feature to API Manager. Do you see any issues with that?
On Thu, Apr 4, 2019 at 1:56 PM Sampath Rajapakshe <samp...@wso2.com> wrote: > Hi, > > In order to handle the post revocation logic, we have implemented the > OAuthEventInterceptor interface which is in identity-inbound-auth-oauth > feature. To add the written custom Interceptor as an OAuth Event Listener, > product-apim need to have *identity-data-publisher-oauth* feature packed. > Is it okay to add this feature to the product-apim? > > The issue came up with regarding the name of the interceptor which i had > written, The name i had used was OAuthEventInterceptorProxy. With that name > my interceptor get registered as the proxy(Which is also an Interceptor) > for the Interceptors. Default implementation of proxy is to iterate through > the registered interceptors. So the name of my interceptor is now changed > to APIMOAuthEventInterceptor. Now the issue comes ,as this newly created > interceptors registration logic is in *identity-data-publisher-oauth > *feature. > So now it seems we have to add this feature to product apim to enable this > interceptor. > > Thanks, > Regards, > Sampath > > On Tue, Apr 2, 2019 at 5:17 PM Sampath Rajapakshe <samp...@wso2.com> > wrote: > >> Hi All, >> >> I have started documenting the JWT Revocation feature. Please find the >> below document [1] with all the details related to this feature. Any >> feedback is appreciated. >> >> [1] >> https://docs.google.com/document/d/1Znmgx5MlWKKaPLg0JL1oRxhMR5PbqQUPHIs2vnaIuqM/edit?usp=sharing >> >> Thanks, >> Sampath >> >> On Thu, Feb 28, 2019 at 1:56 PM Sanjeewa Malalgoda <sanje...@wso2.com> >> wrote: >> >>> 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 <samp...@wso2.com> >>> 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 <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 >>>> >>>> >>>> >>> >>> -- >>> *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 >>> >> >> >> -- >> >> *Sampath Rajapakse* | Software Engineer | WSO2 Inc. >> >> +94717313761 | samp...@wso2.com >> >> >> > > -- > > *Sampath Rajapakse* | Software Engineer | WSO2 Inc. > > +94717313761 | samp...@wso2.com > > > -- *Harsha Kumara* Associate Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: hars...@wso2.coim Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
