Hi Ruwan, On Thu, Nov 3, 2016 at 1:42 PM, Ruwan Yatawara <[email protected]> wrote:
> 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? > I think the user first enrolls the device right, in that case I believe some APIs such as enrollment API needs to be password grant type, and then after it needs to be user+device, which could be an extended custom grant type implementation. WDYT? Thanks, Sinthuja. > > >> >> >>> 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 > > -- *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
