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. 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
