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

Reply via email to