Shall we have a meeting, get all our views and come to a conclusion. ? On Thu, Nov 3, 2016 at 2:56 PM, Ayyoob Hamza <[email protected]> wrote:
> Please find my comments inline. > > >> Hi All >>>> >>>> Currently IOT communicates with APIM components via Java/OSGI api's and >>>> services. Therefore $subject is needed to properly decouple and make IOT >>>> cloud ready. >>>> Consider the following points where IOT uses APIM. Sub-points are huw >>>> i'm planing to implement >>>> >>>> *1. At server startup - It creates and publish apis to APIM* >>>> 1.1 Creates a client using DCR-endpoint - [1] >>>> 1.2 Gets a token from token-endpoint using the consumer key/secret >>>> received from 1.1 - [2] >>>> 1.3 Creates api from publisher apis using the token received at 1.2 - >>>> [3] >>>> 1.4 Publish api (change life-cycle to PUBLISHED), using the token >>>> received at 1.2 and api-ID received from 1.3 -[4] >>>> >>> >>>> *2. Before an api call * >>>> 2.1 Create a app calling DCR endpoint[1] - get consumer/key secret >>>> 2.2 Get a token for the app created in 2.1 by calling token-endpoint[2] >>>> 2.3 Create auth app (needs the token received in 2.2) using >>>> publisherApi[5] >>>> >>> >>> I think from here you meant store API right, not publisher API. I don't >>> think we do have create application, subscription, etc details from >>> publisher API, rather it's from store APIs. >>> >>> >>>> 2.4 Search apis from a given tag using publisherApi[6] >>>> 2.5 Subscribe to apis (from 2.4) to the app created in 2.3 (needs the >>>> token received in 2.2) - using publisherApi[7] >>>> >>> >>> In addition to above we also, need to consider a case where the APIs are >>> getting published after the API application is getting created, ie, future >>> APIs. If any APIs that are created later after the application is created, >>> will also need to be subscribed from the created application. >>> >> >> Yes, this needs to be acomodated. Maybe we can have this configured as an >> action during api lifecycle transition. >> >>> >>> Yes, currently we do this by getting the list of apis that its > subscribed for a given app and then we subscribe the additional apis that > needs to be subscribed when the jaggery app is redeployed. > APIPublisherService in the webapp publisher needs to cater this for rest > api implementation. > > Are we registering one application for all APIs that is there in the >>> system? In that case are we going to create application with Unlimilted >>> tier? How are we handling the subscription tier related information for the >>> published APIs? >>> >> currently we register one application to all the apis. We earlier decided > to improve this by allowing to subscribe tenants device type apis + cdmf > core apis only. This can be achieved by tags. > This application is for the jaggery app, so currently we have allowed the > subscription for unlimited tier. > > >> >>> >>>> 2.6 Generate keys for app (2.3) (needs the token received in 2.2) - >>>> using publisherApi[8] >>>> 2.7 Get a token from token-endpoint[2] using consumer key/secret >>>> received at 2.6 above. >>>> >>>> *3. When invoking an API - Does the key validation via APIM* >>>> 3.1 Uses the token created at 2.7 >>>> >>>> *4. When device publish its events to MQTT - Does the key validation >>>> via APIM* >>>> *?* >>>> >>>> *Endpoints being call* >>>> [1] - http://localhost:9763/client-registration/v0.9/register >>>> [2] - https://localhost:8243/token >>>> [3] - https://localhost:9443/api/am/publisher/v0.10/apis >>>> [4] - https://localhost:9443/api/am/publisher/v0.10/apis/change- >>>> lifecycle?apiId=<id> >>>> [5] - https://localhost:9443/api/am/store/v0.10/applications >>>> [6] - https://localhost:9443/api/am/store/v0.10/apis >>>> [7] - https://localhost:9443/api/am/store/v0.10/subscriptions >>>> [8] - https://localhost:9443/api/am/store/v0.10/applications/gen >>>> erate-keys?applicationId=<id> >>>> >>>> *Configs needed* >>>> (1.1) - DCREndpoint, username and password of a user who has >>>> permissions to create client-app, callbackUrl,client >>>> Name,tokenScope,owner,grantTypem, saasApp >>>> (1.2) - TokenEndpoint, username, (password if we use password >>>> grant-type), certificate + certPassword if use jwt grant-type >>>> (1.3 - 1.4) - PublisherApiEndpoint >>>> (2.1) - DCREndpoint, username and password of a user who has >>>> permissions to create client-app >>>> (2.2) - TokenEndpoint, username (and password if we use password >>>> grant-type) >>>> (2.3) - StoreApiEndpoint, username and password of a user who has >>>> permissions to create auth-app, throttlingTier, description, name, >>>> callbackUrl >>>> (2.4) - StoreApiEndpoint, tags >>>> (2.5) - StoreApiEndpoint, tier >>>> (2.6) - StoreApiEndpoint, >>>> (2.7) - TokenEndpoint, username (password of the *logged in user* if >>>> we use password grant-type), certificate + certPassword if use jwt >>>> grant-type >>>> >>>> *Questions* >>>> Q1. Can we make 1.1 and 2.1 apps to be SaaS apps >>>> >>> Since we support multi tenancy in single server, we have to create a > saas app to make the app to access other tenant space. An issue that I see > is that if we have to publish the apis to its own tenant space. Currently > we have the publisher user configured in web.xml for a web app. so we have > to create a token for that user. we cant use the password grant type rather > it should be better to use the JWT grant type to retrieve a token on behalf > of the user. > > Q2. Can we use a single (same) app for both 1.1 and 1.2 >>>> >>> >>> I believe here you mean 1.1 and 2.1, where you create DCR apps right? >>> IMO yeah, I don't see a need to have two separate application registered to >>> invoke store and publisher APIs. >>> >> > We can create a single app but both are in two different features, so I > was wondering what would be the best approach. we initially designed api > publishing feature to be used by any product. > >> >>> >>>> Q3. What is the grant-type we will be using >>>> >>> >>> IMO we need to use grant type which could get have the final API >>> invocation user specific details, and hence I think we should go to >>> password grant type, or SAML grant type. >>> >> >> The password grant type nor saml would work in this scenario IMO, as >> device identity needs to be considered. Cant we modifiy the existing custom >> grant type we have to accomdate this scenario? >> > >>> >>>> Q4. What would be the additional requirements if we consider >>>> multi-tenancy >>>> >>> >>> I don't think the current DCR endpoint will allow to create apps in >>> another tenant, and hence when each tenant is getting registered or login >>> to the system for the first time, we need create per tenant based DCR >>> applications (for Publisher and Store API), and API store applications for >>> the device to invoke. >>> >> I think we can create a saas application, if we are to create a dcr app > for each tenant then we have to maintain credential for each tenant to call > the dcr endpoint. however we have to create an api store application for > each tenant. > > >> >>> Q5. Do we perform 1.* in every-time when server starts up >>>> >>> >>> I think we need check if the application is already registered or so, >>> and then register the applications if needed. May be we can have a flag in >>> a persistence store to indicate this during the initialisation phase. As >>> mentioned above, not only in the initialization phase this also need to >>> occur during the tenant initialisation time. >>> >> We dont need to create new application, DCR should handle this, if it is > created then it should give those app information or create new > application. This was discussed in [Behavior of OAuth > 2.0 Dynamic Client Registration]. If it is not the case then android will > have an issue(install the app -> login -> uninstall the app -> install the > app again). > >> >>> >>>> Q6. Can we save the token of the logged-in user in 2.7, either >>>> in-memory or in registry >>>> >>> >>> I think we need to store it in the persistence store, not in memory >>> since we need the refreshToken to renew the accessToken. And also in the >>> end user device, similarly the token needs to be stored and used for the >>> invocations. >>> >>> I think for android we store it in the shared preference(need to > verify), but for UI this is currently added to the session of the user who > logs in. > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Susinda Perera* Software Engineer B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) Mobile:(+94)716049075 Blog: susinda.blogspot.com WSO2 Inc. http://wso2.com/ Tel : 94 11 214 5345 Fax :94 11 2145300
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
