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,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 >>> >> 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
