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 <[email protected]> wrote: > @Hasintha Indrajee <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sampath Rajapakse* | Software Engineer | WSO2 Inc. >>>>> >>>>> +94717313761 | [email protected] >>>>> >>>>> >>>>> >>>> >>>> -- >>>> *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 >>>> >>> >>> >>> -- >>> >>> *Sampath Rajapakse* | Software Engineer | WSO2 Inc. >>> >>> +94717313761 | [email protected] >>> >>> >>> >> >> -- >> >> *Sampath Rajapakse* | Software Engineer | WSO2 Inc. >> >> +94717313761 | [email protected] >> >> >> > > -- > > *Harsha Kumara* > > Associate Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: [email protected] > Blog: harshcreationz.blogspot.com > > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > -- Hasintha Indrajee WSO2, Inc. Mobile:+94 771892453
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
