Hi Sinthuja, Please find my comments inline.
Thanks and Regards, Ruwan Yatawara Associate Technical Lead, WSO2 Inc. email : [email protected] mobile : +94 77 9110413 blog : http://ruwansrants.blogspot.com/ https://500px.com/ruwan_ace www: :http://wso2.com On Thu, Nov 3, 2016 at 1:18 PM, Sinthuja Ragendran <[email protected]> wrote: > 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. > Yes, this needs to be acomodated. Maybe we can have this configured as an action during api lifecycle transition. > > 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. > 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. > > 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
