Is this feature currently available on any pre released packs? On Tue, Apr 23, 2019 at 8:30 AM Pushpalanka Jayawardhana <la...@wso2.com> wrote:
> > > On Thu, 4 Apr 2019 at 17:47, Hasintha Indrajee <hasin...@wso2.com> wrote: > >> I think it's fine to install this to APIM as well. This is where all >> OAuth related audit logs are also logged. (OAuthTokenIssuanceLogPublisher, >> PasswordGrantAuditLogger.. etc). >> >> On Thu, Apr 4, 2019 at 3:19 PM Harsha Kumara <hars...@wso2.com> wrote: >> >>> @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? >>> >> +1 on this. > Without this feature within APIM, it seems to face issues in triggering > listeners based on OAuth events. For example, if we want to trigger an > event at the post or pre-revocation of tokens, this feature is required to > trigger those listeners as well. > > Thanks, > >> >>> 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 >>> >> >> >> -- >> Hasintha Indrajee >> WSO2, Inc. >> Mobile:+94 771892453 >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Pushpalanka. > -- > Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). > Associate Tech Lead, WSO2 Lanka (pvt) Ltd; wso2.com/ > Mobile: +94779716248 > Blog: pushpalankajaya.blogspot.com/ | LinkedIn: > lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka > > > _______________________________________________ > 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
