Hi, As Lakmali has explained the reason for suggesting to skip the subscription is because these webapps do not have valid subscription to the APIs created/to-be-created by the API developers. Therefore all requests made by these Apps to the Gateway will fail at the subscription validation stage unless it is explicitly skipped.
However, skipping the subscription validation will introduce a lot more loopholes to fill in. Therefore I suggest we do the following. *To prevent skipping the subscription* Register the Store and Publisher Applications as standard Applications on API Manager. These apps will belong to the admin user and hence not show up on other user's App listing pages. If required we can skip displaying these Apps on the UI of the admin too. Whenever an API is created, automatically create a subscription for that API for both these Apps using a predefined throttling tier. App creation workflows and Subscription workflows should ignore these two Apps. *To prevent all users getting the same token as the test token* If we use the client_credentials grant to get test tokens, all users of the Publisher and Store would end up getting the same token for testing. This might be a problem when accessing resources protected via scopes since different users have different privileges and hence would require tokens with different scopes. If we use the JWT grant instead of the client_credentials grant, we can get a token per user without the explicit need of the user having to present his credentials. As long as a user has a valid access token to use the product APIs, we can use that as the trust and get him a token for testing his APIs using the JWT grant. I suggest we start implementing this on the Publisher App only for now. Since on the Store we already do have a mechanism of getting a test token (not the most ideal one, but it works!), we can give it second priority. Thanks, NuwanD. On Thu, Mar 23, 2017 at 10:46 AM, Lakmali Baminiwatta <[email protected]> wrote: > Hi Sumedha, > > On 23 March 2017 at 09:06, Sumedha Rubasinghe <[email protected]> wrote: > >> >> >> On Thu, Mar 23, 2017 at 8:28 AM, Lakmali Baminiwatta <[email protected]> >> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> /sumedha >> m: +94 773017743 <+94%2077%20301%207743> >> b : bit.ly/sumedha >> >> _______________________________________________ >> 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
