On Wed, Nov 28, 2018 at 10:59 AM Nadeesha Gamage <[email protected]> wrote:
> Hi Nuwan, > Please find my response below > > On Tue, Nov 27, 2018 at 6:00 PM Nuwan Dias <[email protected]> wrote: > >> >> >> On Tue, Nov 27, 2018 at 4:37 PM Nadeesha Gamage <[email protected]> >> wrote: >> >>> Hi Nuwan, >>> My concern is based on the following two scenarios >>> >>> *Scenario 1 (for security)* >>> - An API Publisher publish the API "xyz" to which the visibility is >>> restricted only to a given set of roles. The API would be deployed on MG. >>> - User A would not be in the correct role to see the "xyz"API (in API >>> store), but has general access to the store and other APIs available. User >>> A can now generated a JWT that is trusted by MG. >>> - User A simply generates a token without any APIs subscribed under the >>> application so that JWT would have an empty claim under "SubscribedAPIs" >>> - User A gets hold of the url of API "xyz" and would now be able to >>> invoke the API even though he has no subscription or visibility to that >>> particular API. >>> >>> If you want to restrict the access to an API, restricting it just by >> subscriptions is not sufficient. This is why there are scopes to be able to >> protect resources of API at the runtime. Things like scopes are supported >> on the API definition itself and therefore these are applied on the API >> runtime irrespective of the subscriptions. >> > ack, shouldnt we provide atleast a message to let the publishers know that > subscription tiers may not be enforced on requests that comes via the MG. > >> >>> >>> *Scenario 2 (for throttling)* >>> - An API Publisher wants to control access to an API based on different >>> HTTP verbs, resources or even based on different roles. >>> - Even after enforcing these limits at different levels (via the >>> publisher) a subscriber who has a valid JWT generated from the store can >>> still access the API without been confined to App, API or resource level >>> throttling limits set by the publisher. >>> >> >> What you are describing here are API level rate limiting options. Which >> are again supported irrespective of subscriptions. The only rate limit >> dependent on the subscription is the subscription tier. >> > ack > >> >>> Nadeesha >>> >>> >>> On Tue, Nov 27, 2018 at 2:56 PM Nuwan Dias <[email protected]> wrote: >>> >>>> It doesn't by pass the security Nadeesha. You are mandated to send a >>>> valid security token to the Gateway, without which you cannot access any >>>> secured resources. >>>> >>>> The only thing you get with a subscription is the rate at which you are >>>> allowed to access an API. In the default behavior of the product we default >>>> that rate limit to a certain limit which is lower than all other defaults. >>>> If someone is not ok with that limit, then can further reduce or increase >>>> it. >>>> >>>> On Tue, Nov 27, 2018 at 10:16 AM Nadeesha Gamage <[email protected]> >>>> wrote: >>>> >>>>> Hi Nuwan, >>>>> In my option API Microgateway should honor the throttling limits and >>>>> access limitations set by the API Manager product irrespective of the fact >>>>> that we are planning to make it interoperable with 3rd party products and >>>>> open standards. If we allow any request that has a valid JWT to access >>>>> APIs >>>>> in the micro gateway then there should be an option for API >>>>> creators/publishers to consent this behaviour for their APIs. Otherwise we >>>>> are creating a back channel to bypass the security and throttling (which >>>>> API creator/publisher enforces through the API Publisher). >>>>> >>>>> >>>>> Nadeesha >>>>> >>>>> On Sun, Nov 18, 2018 at 6:16 PM Harsha Kumara <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Nov 18, 2018 at 5:27 AM Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, 18 Nov 2018 at 9:48 am, Nadeesha Gamage <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Nuwan, >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Nov 18, 2018 at 5:43 AM Nuwan Dias <[email protected]> wrote: >>>>>>>> >>>>>>>>> In the Microgateway the concept of a subscription is optional. >>>>>>>>> This is because the Microgateway is designed as an independent >>>>>>>>> gateway that >>>>>>>>> can run with or without a full API Management system in place. >>>>>>>>> Therefore as >>>>>>>>> long as the Microgateway receives a valid JWT it trusts, it allows the >>>>>>>>> request to pass through. If the JWT contains details of a >>>>>>>>> subscription it >>>>>>>>> will honour it, otherwise it will default to predefined limits for >>>>>>>>> other >>>>>>>>> policies. >>>>>>>>> >>>>>>>>> The idea of micro-* products is to provide developer first >>>>>>>>> experiences for better agility. Hence the motivation for decoupling >>>>>>>>> the >>>>>>>>> gateway runtime as much as possible from the API Management. This way >>>>>>>>> developers can use the MG with a token obtained from any sts that is >>>>>>>>> trusted by the MG (IS, Okta, Ping, etc). >>>>>>>>> >>>>>>>> >>>>>>>> I strongly feel that this should be provided as an option when >>>>>>>> publishing the API, because we allow a creator/publisher to set >>>>>>>> throttling >>>>>>>> limits and define what token types should be accepted and the MG does >>>>>>>> not >>>>>>>> honor any of that. Based on the current MG behaviour I feel our story >>>>>>>> on >>>>>>>> API Management is broken and both standard GW and MG cannot co-exist >>>>>>>> with >>>>>>>> this behaviour. >>>>>>>> >>>>>>> >>>>>>> Also note that the next release of the Microgateway will not even >>>>>>> require an API Management system at all. You can simply create a >>>>>>> Microgateway runtime from a swagger file and run it in isolation. So the >>>>>>> concept of publishing doesn’t even come into the picture. >>>>>>> >>>>>>> We are moving away from the Center of excellence mode of operations. >>>>>>> And unless there is any logical reasoning to do so we won’t be thinking >>>>>>> that the regular gateway and Microgateway should have consistent >>>>>>> behaviour. >>>>>>> >>>>>>> BTW, we are discussing this on a completely wrong thread. We should >>>>>>> discuss this in public. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> @Nuwan Bandara <[email protected]> what your thoughts? >>>>>>>> >>>>>>>> >>>>>>>>> On Sun, 18 Nov 2018 at 1:01 am, Nalaka Senarathna < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> HI All, >>>>>>>>>> >>>>>>>>>>> From APIM 2.6 onwards we have introduced a feature to invoke an >>>>>>>>>>> API with a valid JWT and this doesn’t need to have subscription >>>>>>>>>>> details. >>>>>>>>>>> The idea here is that users can use any valid jwt and we only check >>>>>>>>>>> the >>>>>>>>>>> signature verification. >>>>>>>>>>> >>>>>>>>>>> But if the JWT contains the subscription info then we should >>>>>>>>>>> verify and only allow if it matches. >>>>>>>>>>> >>>>>>>>>>> @Nalaka: thoughts? >>>>>>>>>>> >>>>>>>>>> Correct pubudu. >>>>>>>>>> >>>>>>>>>> IMO this needs to be fixed, if we want to allow access to APIs >>>>>>>>>>> for users with a valid JWT (even though they dont have a valid >>>>>>>>>>> subscription) then that should be something that should be >>>>>>>>>>> configured at an >>>>>>>>>>> API level. >>>>>>>>>>> >>>>>>>>>> So far we build the micro-gateway distribution for API for >>>>>>>>>> already published API in APIM. The reason behind to made this >>>>>>>>>> feature is to >>>>>>>>>> build the micro-gateway distribution directly from the swagger >>>>>>>>>> definition. >>>>>>>>>> In this point, we can't configure from API level. >>>>>>>>>> >>>>>>>>>> [1]Skipping subscription in micro-gateway to allow access to >>>>>>>>>> valid JWT >>>>>>>>>> >>>>>>>>>> Thanks. Regards >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, Nov 17, 2018 at 11:16 PM Nadeesha Gamage < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> At the moment the behaviour is flowed and here is why >>>>>>>>>>> 1. Anyone who has access to the store can access any API exposed >>>>>>>>>>> via MG without a valid subscription. >>>>>>>>>>> 2. Given that subscriptions are not honored there is no way of >>>>>>>>>>> throttling APIs. >>>>>>>>>>> >>>>>>>>>>> IMO this needs to be fixed, if we want to allow access to APIs >>>>>>>>>>> for users with a valid JWT (even though they dont have a valid >>>>>>>>>>> subscription) then that should be something that should be >>>>>>>>>>> configured at an >>>>>>>>>>> API level. >>>>>>>>>>> >>>>>>>>>>> Nadeesha >>>>>>>>>>> >>>>>>>>>>> On Sat, Nov 17, 2018 at 10:51 AM Harsha Kumara <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Nov 17, 2018 at 12:12 AM Rajith Roshan < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Harsha, >>>>>>>>>>>>> The idea behind is allow to access apis exposed via micro gw >>>>>>>>>>>>> if user has a valid token from a trusted STS. Make subscription >>>>>>>>>>>>> validation >>>>>>>>>>>>> configurable in micro gw is something we can do. But that will >>>>>>>>>>>>> not allow >>>>>>>>>>>>> apis to be invoked from a third party key manager. Then thers >>>>>>>>>>>>> should be set >>>>>>>>>>>>> of micro gws with subscription validation and set without >>>>>>>>>>>>> subscription >>>>>>>>>>>>> validation. This will make deployment kind of complex. Wdyt >>>>>>>>>>>>> >>>>>>>>>>>> How about sending empty claim if there is no subscription? So >>>>>>>>>>>> we can make sure that person who use store subscriptions can't use >>>>>>>>>>>> APIs >>>>>>>>>>>> unless they subscribed? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, 17 Nov 2018, 10:31 Harsha Kumara <[email protected] >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> But it should be enabled separately. How we can enforce >>>>>>>>>>>>>> person who comes to store should need valid subscription to >>>>>>>>>>>>>> invoke a API? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Nov 16, 2018 at 11:35 PM Pubudu Gunatilaka < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From APIM 2.6 onwards we have introduced a feature to invoke >>>>>>>>>>>>>>> an API with a valid JWT and this doesn’t need to have >>>>>>>>>>>>>>> subscription details. >>>>>>>>>>>>>>> The idea here is that users can use any valid jwt and we only >>>>>>>>>>>>>>> check the >>>>>>>>>>>>>>> signature verification. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But if the JWT contains the subscription info then we should >>>>>>>>>>>>>>> verify and only allow if it matches. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @Nalaka: thoughts? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Nov 17, 2018 at 3:11 AM Harsha Kumara < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you create a JWT and then if it allowed to invoke APIs >>>>>>>>>>>>>>>> which subscribed aftrwards then it's a bug. We should fix it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Nov 16, 2018 at 3:23 PM Nadeesha Gamage < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi team, >>>>>>>>>>>>>>>>> MG is allowing requests to go through even if the >>>>>>>>>>>>>>>>> application associated with the JWT doesnt have a >>>>>>>>>>>>>>>>> subscription to the API. >>>>>>>>>>>>>>>>> Please find the screenshots below. Is this by design or is >>>>>>>>>>>>>>>>> this a bug? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [image: image.png] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [image: image.png] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Nadeesha Gamage >>>>>>>>>>>>>>>>> Senior Lead Solutions Engineer >>>>>>>>>>>>>>>>> T : +94 77 394 5706 >>>>>>>>>>>>>>>>> B : https://nadeesha678.wordpress.com/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> *Pubudu Gunatilaka* >>>>>>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> *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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Nadeesha Gamage >>>>>>>>>>> Senior Lead Solutions Engineer >>>>>>>>>>> T : +94 77 394 5706 >>>>>>>>>>> B : https://nadeesha678.wordpress.com/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Nalaka Senarathna* >>>>>>>>>> *Associate Software Engineer | WSO2* >>>>>>>>>> >>>>>>>>>> *Email : [email protected] <[email protected]>* >>>>>>>>>> *Mobile : +94714118474* >>>>>>>>>> *web : https://wso2.com <https://wso2.com>* >>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> *Nuwan Dias* | Director | WSO2 Inc. >>>>>>>>> (m) +94 777 775 729 | (e) [email protected] >>>>>>>>> [image: Signature.jpg] >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nadeesha Gamage >>>>>>>> Senior Lead Solutions Engineer >>>>>>>> T : +94 77 394 5706 >>>>>>>> B : https://nadeesha678.wordpress.com/ >>>>>>>> >>>>>>> -- >>>>>>> *Nuwan Dias* | Director | WSO2 Inc. >>>>>>> (m) +94 777 775 729 | (e) [email protected] >>>>>>> [image: Signature.jpg] >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nadeesha Gamage >>>>> Senior Lead Solutions Engineer >>>>> T : +94 77 394 5706 >>>>> B : https://nadeesha678.wordpress.com/ >>>>> >>>> >>>> >>>> -- >>>> *Nuwan Dias* | Director | WSO2 Inc. >>>> (m) +94 777 775 729 | (e) [email protected] >>>> [image: Signature.jpg] >>>> >>> >>> >>> -- >>> Nadeesha Gamage >>> Senior Lead Solutions Engineer >>> T : +94 77 394 5706 >>> B : https://nadeesha678.wordpress.com/ >>> >> >> >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) [email protected] >> [image: Signature.jpg] >> > > > -- > Nadeesha Gamage > Senior Lead Solutions Engineer > T : +94 77 394 5706 > B : https://nadeesha678.wordpress.com/ > -- *Harsha Kumara* Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: [email protected] Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
