Hi Sumedha, On 23 March 2017 at 09:06, Sumedha Rubasinghe <sume...@wso2.com> wrote:
> > > On Thu, Mar 23, 2017 at 8:28 AM, Lakmali Baminiwatta <lakm...@wso2.com> > wrote: > >> Hi all, >> >> Prior to C5, we were generating an access token per app created in the >> store using the client_credentials grant type and it was displayed to be >> used as the test tokens. The same was used in the API Console as well. Due >> to below reasons we are going to generate a token against the OAuth app >> registered for the UUF app and make it available as the test token. >> >> - Ideally the UI application (ex: store) is the real application >> which does the test API calls. >> - People get it confused with the application tokens we provide in >> the store and use those in the real use cases. >> - Make it possible to do a test API call without subscribing. >> - Provide Swagger API Console in Publisher as well. >> >> 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. >> > > Why skip subscription check? If UI app's capabilities are properly mapped > to API resources with correct scopes, it's ok to treat this as a normal > application subscribing to bunch of product APIs. > It seems I have made it bit confusing with the subject. Actually this is about a test token for invoking the APIs published in APIM and not about the product APIs. What we are going to do is get an access token against the OAuth apps registered for the Store and Publisher. So here we are considering as the Store and Publisher web apps are by default subscribed to the managed APIs. Therefore skipping the subscription validation. Thanks, Lakmali > > > > >> 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. >> >> > I think you should also get device id/brower id into this combination as > well. A given user can maintain multiple sessions from different > devices/browers concurrently. (eg: for statistics dashboards) > > > >> >> - 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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > /sumedha > m: +94 773017743 <+94%2077%20301%207743> > b : bit.ly/sumedha > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
