Yes, this is not part of the spec. Its implemented as such because this is a problem which is unique to us and its a result of the product's architecture. And there is no known generic solution yet on how to handle it when using third party key managers. But that shouldn't mean we should at least fix it for our own key manager. People would accept limitations when they're using their own key managers but they wouldn't accept limitations when using our own key manager. So unless we find a generic solution which works across everything, its fine to live with it IMO as long as it doesn't have any undesired impacts. If you have any suggestions on how to fix it globally you could contribute with your ideas.
However, this now doesn't look like a bug to me. Although the JiRA has been reported as a bug. Thanks, NuwanD. On Sat, Jun 25, 2016 at 8:32 PM, Kavitha Subramaniyam <kavi...@wso2.com> wrote: > Hi Nuwan, > > Thank you for the response.. > I have been understood the behavior and there is no security risk when > revoked token values returning to the response endpoint. > > But as per my understanding, when we use third party key manger that will > not let to know the gateway to do cache clear like in our implementation > the key manager gives the knowledge and the gateway relies on that to clear > its caches.. Since our implementation is not part of spec, I thought to > create a jira to track this in APIM and if apim would give any solution for > this.. I shall add the comment to the jira as well. > > > Thanks, > Kavitha > > On Fri, Jun 24, 2016 at 6:55 PM, Nuwan Dias <nuw...@wso2.com> wrote: > >> Any idea why its bad? That jira doesn't clearly say why. It won't return >> anything in those headers if someone sends invalid values. So I'm wondering >> how it can be bad. >> >> The reason we use these return values is to clear the gateway cache. When >> the key manager refreshes a token, the Gateway doesn't know which access >> token was revoked. So it has no knowledge of which tokens to clear from its >> cache. Any suggestions on alternative approaches of clearing the cache in >> those scenarios? >> >> Thanks, >> NuwanD. >> >> On Fri, Jun 24, 2016 at 6:25 PM, Aparna Karunarathna <apa...@wso2.com> >> wrote: >> >>> Hi Nuwan, >>> >>> Kavitha was asking, RevokedAccessToken & RevokedRefreshToken are >>> getting in the header because it was requested requirement by APIM team [1] >>> ? Jira [1] says it's a bad implementation. So are we going to fix[2] ? >>> >>> [1] https://wso2.org/jira/browse/IDENTITY-4112 >>> [2] https://wso2.org/jira/browse/APIMANAGER-5098 >>> >>> Regards, >>> Aparna. >>> >>> On Fri, Jun 24, 2016 at 5:44 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> Can you explain what the issue here is? You have raised the ticket as a >>>> bug but you've forgotten to describe what the bug actually is? >>>> >>>> On Fri, Jun 24, 2016 at 5:39 PM, Kavitha Subramaniyam <kavi...@wso2.com >>>> > wrote: >>>> >>>>> Hi apim team, >>>>> A jira has been raised to track this issue in [1] >>>>> >>>>> [1] https://wso2.org/jira/browse/APIMANAGER-5098 >>>>> >>>>> Thanks, >>>>> >>>>> On Thu, Jun 23, 2016 at 6:31 PM, Kavitha Subramaniyam < >>>>> kavi...@wso2.com> wrote: >>>>> >>>>>> Hi team, >>>>>> Highly appreciate your update on this. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> On Wed, Jun 22, 2016 at 2:28 PM, Kavitha Subramaniyam < >>>>>> kavi...@wso2.com> wrote: >>>>>> >>>>>>> Hi team, >>>>>>> >>>>>>> I observed that both revoked access and revoked refresh tokens were >>>>>>> returning in http response header [3]. >>>>>>> setup : IS as KM >>>>>>> - apim 2.0.0 17th nightly build >>>>>>> - IS 5.2.0 19th build >>>>>>> - Token encryption enabled >>>>>>> >>>>>>> Could you please confirm that this behavior is not resolved >>>>>>> purposely in apim 2.0.0 due to the reasons discussed in mail thread >>>>>>> [1], or >>>>>>> it has been solved? >>>>>>> Find an identity jira was raised for IS issue [2] >>>>>>> >>>>>>> [1] Revoked Access Token and Revoked Refresh Token returned back in >>>>>>> token revoke endpoint response >>>>>>> >>>>>>> [2] https://wso2.org/jira/browse/IDENTITY-4112 >>>>>>> >>>>>>> [3] >>>>>>> >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> HTTP/1.1 200 OK >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> AuthorizedUser: WSO2.ORG/admin@carbon.super >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> Cache-Control: no-store >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << Date: >>>>>>> Wed, 22 Jun 2016 08:39:00 GMT >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> Pragma: no-cache >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> RevokedAccessToken: 030415a3-7b8a-39e7-b154-28cec1aeaf89 >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> RevokedRefreshToken: >>>>>>> h56lM3zcJNCBbPHJfGnbQpUcI/ocp6CzGaE+r53nYDM021ItoJP4T/tN8fYGkQq6vvke4PwfkMQEt1zP7HNHJwgynI6Ch86C1tNCthxsG2CKsthHvjsGXvOzktURrNUGxJboj+U/r9arQc/mEt/J0skFQm1R76IC9Zlgh/5irBU= >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> Content-Type: text/html >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> Content-Length: 0 >>>>>>> [2016-06-22 14:09:00,745] DEBUG - headers http-outgoing-10 << >>>>>>> Server: WSO2 Carbon Server >>>>>>> [2016-06-22 14:09:00,747] DEBUG - headers http-incoming-13 << >>>>>>> HTTP/1.1 200 OK >>>>>>> [2016-06-22 14:09:00,747] DEBUG - headers http-incoming-13 << >>>>>>> RevokedAccessToken: 030415a3-7b8a-39e7-b154-28cec1aeaf89 >>>>>>> [2016-06-22 14:09:00,747] DEBUG - headers http-incoming-13 << >>>>>>> AuthorizedUser: WSO2.ORG/admin@carbon.super >>>>>>> [2016-06-22 14:09:00,748] DEBUG - headers http-incoming-13 << >>>>>>> RevokedRefreshToken: >>>>>>> h56lM3zcJNCBbPHJfGnbQpUcI/ocp6CzGaE+r53nYDM021ItoJP4T/tN8fYGkQq6vvke4PwfkMQEt1zP7HNHJwgynI6Ch86C1tNCthxsG2CKsthHvjsGXvOzktURrNUGxJboj+U/r9arQc/mEt/J0skFQm1R76IC9Zlgh/5irBU= >>>>>>> [2016-06-22 14:09:00,748] DEBUG - headers http-incoming-13 << >>>>>>> Content-Type: text/html >>>>>>> [2016-06-22 14:09:00,748] DEBUG - headers http-incoming-13 << >>>>>>> Pragma: no-cache >>>>>>> [2016-06-22 14:09:00,748] DEBUG - headers http-incoming-13 << >>>>>>> Cache-Control: no-store >>>>>>> [2016-06-22 14:09:00,748] DEBUG - headers http-incoming-13 << Date: >>>>>>> Wed, 22 Jun 2016 08:39:00 GMT >>>>>>> [2016-06-22 14:09:00,748] DEBUG - headers http-incoming-13 << >>>>>>> Transfer-Encoding: chunked >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -- >>>>>>> Kavitha.S >>>>>>> *Software Engineer -QA* >>>>>>> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194> >>>>>>> kavi...@wso2.com <thili...@wso2.com> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Kavitha.S >>>>>> *Software Engineer -QA* >>>>>> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194> >>>>>> kavi...@wso2.com <thili...@wso2.com> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Kavitha.S >>>>> *Software Engineer -QA* >>>>> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194> >>>>> kavi...@wso2.com <thili...@wso2.com> >>>>> >>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Technical Lead - WSO2, Inc. http://wso2.com >>>> email : nuw...@wso2.com >>>> Phone : +94 777 775 729 >>>> >>> >>> >>> >>> -- >>> *Regards,* >>> >>> *Aparna Karunarathna.* >>> >>> >>> *Associate Technical Lead - QAWSO2 Inc.Mobile: 0714002533* >>> >> >> >> >> -- >> Nuwan Dias >> >> Technical Lead - WSO2, Inc. http://wso2.com >> email : nuw...@wso2.com >> Phone : +94 777 775 729 >> > > > > -- > Kavitha.S > *Software Engineer -QA* > Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194> > kavi...@wso2.com <thili...@wso2.com> > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
