On Thu, Mar 23, 2017 at 7:12 PM, Nuwan Dias <[email protected]> wrote: > > > On Thu, Mar 23, 2017 at 9:04 PM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> >> >> On Thu, Mar 23, 2017 at 12:17 PM, Nuwan Dias <[email protected]> wrote: >> >>> >>> >>> On Thu, Mar 23, 2017 at 3:15 PM, Joseph Fonseka <[email protected]> wrote: >>> >>>> I guess there is a possibility of that API developer not being the one >>>> who publish / create the API ? >>>> >>> >>> Yes, the API Developer may not be the same one who's publishing the it. >>> But what's wrong with him testing the API under development using a valid >>> token? >>> >> If this is valid argument then person who create APIs can consume it. If >> we consider scenario where we develop API and later it published and appear >> in gateways, just because I'm developer will i get chance to use this API? >> I don't think we should allow it. Even if we say we are testing what >> actually happen is someone invoke API and get results. >> > > In API Manager 3.0.0, the API deployment to the Gateway happens before the > Publishing phase actually. It gets deployed on the Gateway as soon as its > created. > Why do we deploy API to gateway by the time we created it? Ideally it should go to topic and notified only after publishing it. I haven't noticed it any of our previous discussions. Did i missed something here?
Thanks, sanjeewa. > > If the API developer accessing a published API with a valid token is a > concern, we can automatically remove the publisher webapp's subscription to > the API once the API gets published. This will prevent the API developers > and publishers from accessing a published API since they no longer have a > valid subscription. > >> >> >> Thanks, >> sanjeewa. >> This can be an edge case, but if you consider an API designed to work >> with client credentials ie. B2B API, subscription is the authorization >> point for that API if so you don't want the creator or publisher on >> accessing it ? >> >> I guess it is fare to ask a user to go though subscription process to >> test the published API without magic. WDYT ? >> >>> >>> Well, the point here is that we're trying to provide the facility for >>> the Developer to test the API he's developing before publishing it. Because >>> that's a very valid use case. Asking the developer to publish the API and >>> subscribe to it in order to be able to safely test it is not right IMO. The >>> sole reason he wants to test the API first is because he's not ready to >>> publish it yet. >>> >>>> >>>> Thanks & Regards >>>> Jo >>>> >>>> >>>> >>>> On Thu, Mar 23, 2017 at 2:32 PM, Nuwan Dias <[email protected]> wrote: >>>> >>>>> Why is it a concern? Its only the App developers who have the >>>>> subscriber role. Almost all consumers of the API are general users and >>>>> hence do not have the subscriber role. So why is it a concern to allow the >>>>> person who's developing the API to access it? >>>>> >>>>> On Thu, Mar 23, 2017 at 1:59 PM, Lakmali Baminiwatta <[email protected] >>>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> On 23 March 2017 at 13:46, Joseph Fonseka <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 23, 2017 at 1:01 PM, Lakmali Baminiwatta < >>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> In publisher shouldn't we invoke the API back-end instead of >>>>>>>>> Gateway ? >>>>>>>>> >>>>>>>> >>>>>>>> I guess publisher may need to test the API execution flow through >>>>>>>> gateway. For instance the resource paths, mediation logics, etc. >>>>>>>> >>>>>>> >>>>>>> Yes that make sense, but if we automatically subscribe to a >>>>>>> published API it will allow a user ( ie user with creator role in >>>>>>> publisher >>>>>>> ) who may not have subscription permission to invoke an API. That might >>>>>>> be >>>>>>> a security concern based on a company policy. >>>>>>> >>>>>>> >>>>>> Yes, this can be a valid concern. In that case we can allow this >>>>>> only for users with publish permissions. >>>>>> >>>>>> Thanks, >>>>>> Lakmali >>>>>> >>>>>> Or are we only allowing the test feature in publisher for specific >>>>>>> roles. >>>>>>> >>>>>>> Thanks >>>>>>> Jo >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lakmali >>>>>>>> >>>>>>>>> >>>>>>>>> IMO it would be difficult to explain the mention approach to a >>>>>>>>> user than what we have. >>>>>>>>> >>>>>>>>> Thanks & Regards >>>>>>>>> Jo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The proposed solution is to generate an access token with the UUF >>>>>>>>>> app's credentials + special scope. The subscription validation will >>>>>>>>>> be >>>>>>>>>> skipped for the tokens in this special scope. For implementing the >>>>>>>>>> solution, we have to consider below points. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Grant Type - If the client_credentials grant type is used, >>>>>>>>>> all the concurrent users accessing the UI app will get the same >>>>>>>>>> token. In >>>>>>>>>> order to do any user level restrictions for this token in the >>>>>>>>>> gateway >>>>>>>>>> level, we have to use password grant type. One case is visibility >>>>>>>>>> restricted API invocations. Also I guess we shouldn't allow to >>>>>>>>>> invoke API >>>>>>>>>> resources protected with scopes if the logged in user is not >>>>>>>>>> allowed for >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Scope white listing - This scope has to be white listed, >>>>>>>>>> since the API resource is not actually protected with it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Throttling - Since there is no API subscription, special >>>>>>>>>> throttle limit has to be applied with some minimum quota. One >>>>>>>>>> option is to >>>>>>>>>> apply the unauthenticated tier limits which does a throttling >>>>>>>>>> based on the >>>>>>>>>> client IP. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Token validity and refresh token - If the client_credential >>>>>>>>>> grant type is used, we can't invalidate this test token when a >>>>>>>>>> user is >>>>>>>>>> logged out since other users might be using it already. Therefore >>>>>>>>>> IMO, we >>>>>>>>>> can use password grant type and use the similar token refreshing >>>>>>>>>> mechanism >>>>>>>>>> done for UUF app authentication. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Obtaining the access token - In order to get an access >>>>>>>>>> token, we need the consumer key and secret of the UUF app. >>>>>>>>>> Currently we do >>>>>>>>>> a UUF backend app call only when the user is authenticating or >>>>>>>>>> when >>>>>>>>>> refreshing the token. So here also, I think we can generate the >>>>>>>>>> test token >>>>>>>>>> when the user is authenticated(log in to the UUF app) and store >>>>>>>>>> it in the >>>>>>>>>> local storage. I believe its okay to display this access token >>>>>>>>>> for the >>>>>>>>>> user. >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lakmali >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>> Associate Technical Lead >>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>> blog : lakmali.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Joseph Fonseka* >>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>> lean.enterprise.middleware >>>>>>>>> >>>>>>>>> mobile: +94 772 512 430 >>>>>>>>> skype: jpfonseka >>>>>>>>> >>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Lakmali Baminiwatta >>>>>>>> Associate Technical Lead >>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> mobile: +94 71 2335936 >>>>>>>> blog : lakmali.com >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> -- >>>>>>> *Joseph Fonseka* >>>>>>> WSO2 Inc.; http://wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> mobile: +94 772 512 430 >>>>>>> skype: jpfonseka >>>>>>> >>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lakmali Baminiwatta >>>>>> Associate Technical Lead >>>>>> WSO2, Inc.: http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> mobile: +94 71 2335936 >>>>>> blog : lakmali.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> -- >>>> *Joseph Fonseka* >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 772 512 430 >>>> skype: jpfonseka >>>> >>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 <077%20777%205729> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 <+94%2071%20306%208779> >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <077%20777%205729> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
