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/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
