Why is OAuth2 considered as additional complexity? If you look at it, the publisher UI is already an OAuth app, it already has a pair of client id and client secret so that it can use the product REST APIs. And the API deployed on the Gateway already knows how to validate an OAuth token. We don't have to build anything more.
The only two steps we need to make this work is to get an access token for the publisher UI and to create a subscription. Both which should be straightforward. Regarding basic auth, I'm not sure how it would work because you basically need the user to input his credentials every time he needs to access the API. I was suggesting to use the JWT grant to get a token so that we can get a token for the "user" without expecting his credentials every time. You need it only once, and it could be via direct login or SSO login, doesn't matter. On Fri, Mar 24, 2017 at 10:57 AM, Sanjeewa Malalgoda <[email protected]> wrote: > If user need to test this API for security, scopes based permissions etc > then, yes we need oauth 2 based security model we have in store. > So creating application and all oauth related stuff are mandatory. But do > we really need to go into that detail? Cant we just secure API with basic > auth credentials or JWT based security? With that we can avoid all > complexity of oauth app creation etc. WDYT? > > Thanks, > sanjeewa. > > > On Fri, Mar 24, 2017 at 6:36 AM, Lakmali Baminiwatta <[email protected]> > wrote: > >> The objective of providing this feature is making the API >> developers/publisher to test and verify before make it available for the >> consumers. So how about we provide the ability to deploy it to the gateway >> without security so that it can be invoked without a token? >> Once the test is completed, they can set the security and publish that to >> the store/gateway. >> >> Thanks, >> Lakmali >> >> >> On 24 March 2017 at 09:34, Nuwan Dias <[email protected]> wrote: >> >>> >>> >>> On Thu, Mar 23, 2017 at 11:06 PM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> >>>> >>>> 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? >>>> >>> >>> The cause is the same as before. We want to enable API testing on the >>> publisher itself so that API developers can test their API before >>> publishing it to the Store. In order to test an API, it should be deployed >>> on the Gateway. >>> >>>> >>>> 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 <+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 <+94%2077%20777%205729> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > *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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
