Hi Susinda, Please see my response inline.
On Thu, Nov 3, 2016 at 11:58 AM, Susinda Perera <[email protected]> wrote: > 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. 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? > 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,clientName,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 > 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. > 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. > 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. 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. > 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. Thanks, Sinthuja. > > -- > *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 > > -- *Sinthuja Rajendran* Technical Lead WSO2, Inc.:http://wso2.com Blog: http://sinthu-rajan.blogspot.com/ Mobile: +94774273955
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
