We had a meeting. Participants: Sanjiva, Sumedha, NuwanD, Prabath, Srinath (Prabath please list others joined from Trace)
Problem: Bob writes a API and publish it API manager. Then Alice subscribes to the API and write an mobile APP. Charlie uses the mobile App, which results in an API call. We need to track the API calls via DAS. And when Bob, Alice, and possibly Charlie come to the dashboard server, they should possibly see the transaction from their view. Challenge is that now there is no clear user in the above transaction. Rather there is three. So we cannot handle this generically at the DAS level via a user concept. Hence, the API manager needs to put the right information when it publish data to DAS and show data only to relevant parties when it showing and exposing data. Solution [image: SecuirtyLayers.png] 1. We will keep DAS in the current state with support for tenants without support for users. It is aware about tenant and provide full isolation between tenant. However, it does not aware about users. 2. Each product will write an extended receiver and DAL layer as, that will build an API catered for their use cases. This API will support login via OAuth tokens. Since they know the fields in the tables that has user data init, then can filter the data based on the user. 3. We will run the extended DAL layers and receivers in DAS, and they will talk to DAL as an OSGI call. 4. Above layers will assume that users have access to OAuth token. In APIM use cases, APIM can issue tokens, and in IoT use cases, APIM that runs in the IoT server can issue tokens. Also this means, we will not support users providing their own analytics queries. Only tenant admins can provide their own queries. As decided in the earlier meeting, We need APIM and IOT Server to be able to publish events as "system user", but ask DAS to place data under Ann's ( related user) account. Please add anything I missed. --Srinath On Tue, Mar 29, 2016 at 11:53 AM, Srinath Perera <[email protected]> wrote: > > I have scheduled a meeting tomorrow to discuss this. > > --Srinath > > On Tue, Mar 29, 2016 at 11:44 AM, Sachith Withana <[email protected]> wrote: >> >> Hi all, >> >> I do believe it would be of great value to incorporate user level data isolation for DAS. >> >> Having said that though, it wouldn't be practical to provide a complete permission platform to DAS that would suffice all the requirements of APIM and IOT. >> >> IMO, we should provide some features that would help individual products build their own permission platform that caters to their requirements. >> >> Thanks, >> Sachith >> >> On Tue, Mar 29, 2016 at 10:38 AM, Nuwan Dias <[email protected]> wrote: >>> >>> Please ignore my reply. It was intended for another thread :) >>> >>> On Mon, Mar 28, 2016 at 4:26 PM, Nuwan Dias <[email protected]> wrote: >>>> >>>> Having to publish a single event after collecting all possible data records from the server would be good in terms of scalability aspects of the DAS/Analytics platform. However I see that it introduces new challenges for which we would need solutions. >>>> >>>> 1. How to guarantee a event is always published to DAS? In the case of API Manager, a request has multiple exit points. Such as auth failures, throttling out, back-end failures, message processing failures, etc. So we need a way to guarantee that an event is always sent out whatever the state. >>>> >>>> 2. With this model, I'm assuming we only have 1 stream definition. Is this correct? If so would this not make the analytics part complicated? For example, say I have a spark query to summarize the throttled out events from an App, since I can only see a single stream the query would have to deal with null fields and have to deal with the whole bulk of data even if in reality it might only have to deal with a few. The same complexity would arise for the CEP based throttling engine and the new alerts we're building as well. >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>> On Mon, Mar 28, 2016 at 2:43 PM, Srinath Perera <[email protected]> wrote: >>>>> >>>>> Hi Ayyoob, Ruwan, Suho, >>>>> >>>>> I think where to handle ( within DAS vs. at higher level API in APIM or IoT server) is decided by what level user customizations are needed for analytics queries. >>>>> >>>>> If we need individual users to write their own queries as well, then we need to build user support into DAS. However, if queries can be changed by tenant admins only, doing this via a high-level API is OK. >>>>> >>>>> Where does APIM and IoT server stands on this? >>>>> >>>>> --Srinath >>>>> >>>>> >>>>> >>>>> On Sat, Mar 26, 2016 at 9:28 AM, Ayyoob Hamza <[email protected]> wrote: >>>>> > >>>>> > Hi, >>>>> > Yes we require user level separation but just wondered whether we need this separation in DAS level or whether can we enforce it device type API level. This is because IMO, DAS provides a low level API which we cannot expose it directly so we need a proxy that maps this to a high level API to expose the data. So wondered whether can we do the restriction in the high level API endpoint. However if the user level separation is required across products such as APIM then I guess the separation should be in the DAS level. >>>>> > >>>>> > Further just wanted to bring another concern that we have, we have a requirement on device sharing so what this mean is that we can share the data of a device to another, which means a drill down permission model, where the separation would be in user, device level(eg: Does the user X has permission to view the data of the device d of user Y). So in this case I wonder whether this needs to be handled in DAS level? rather I see that it needs to be handled in the high level API that we provide to expose the data. >>>>> > >>>>> > Thanks >>>>> > >>>>> > >>>>> > Ayyoob Hamza >>>>> > Software Engineer >>>>> > WSO2 Inc.; http://wso2.com >>>>> > email: [email protected] cell: +94 77 1681010 >>>>> > >>>>> > On Sat, Mar 26, 2016 at 1:03 AM, Ruwan Yatawara <[email protected]> wrote: >>>>> >> >>>>> >> Hi Suho, >>>>> >> >>>>> >> Yes, you are right. We require user level isolation in IoT Server. >>>>> >> >>>>> >> Thanks and Regards, >>>>> >> >>>>> >> Ruwan Yatawara >>>>> >> >>>>> >> Senior Software Engineer, >>>>> >> WSO2 Inc. >>>>> >> >>>>> >> email : [email protected] >>>>> >> mobile : +94 77 9110413 >>>>> >> blog : http://ruwansrants.blogspot.com/ >>>>> >> www: :http://wso2.com >>>>> >> >>>>> >> >>>>> >> On Fri, Mar 25, 2016 at 11:55 PM, Sriskandarajah Suhothayan < [email protected]> wrote: >>>>> >>> >>>>> >>> Hi >>>>> >>> >>>>> >>> User level isolation is needed for the IoT server, as in the IoT server context user registers a device and use that, hence he/she should only be able to see his/her devices and not any other users devices or data. >>>>> >>> >>>>> >>> @Pabath & Sumedha correct me if I'm wrong. >>>>> >>> >>>>> >>> Regards >>>>> >>> Suho >>>>> >>> >>>>> >>> On Fri, Mar 25, 2016 at 9:02 AM, Srinath Perera <[email protected]> wrote: >>>>> >>>> >>>>> >>>> For the data published from APIM and IoT servers, what kind of isolation do we need? >>>>> >>>> >>>>> >>>> Option 1: Tenant level - DAS already has this. However, this means that multiple users (e.g. publishers, subscribers, or IoT users) can see other people's stats of they are in the same tenant >>>>> >>>> >>>>> >>>> Option 2: User level - DAS does not have this concept yet. >>>>> >>>> >>>>> >>>> Also a related question is that if user add their own queries, at what level they are isolated. >>>>> >>>> >>>>> >>>> --Srinath >>>>> >>>> >>>>> >>>> -- >>>>> >>>> ============================ >>>>> >>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>>>> >>>> Site: http://home.apache.org/~hemapani/ >>>>> >>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>> >>>> Phone: 0772360902 >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> S. Suhothayan >>>>> >>> Technical Lead & Team Lead of WSO2 Complex Event Processor >>>>> >>> WSO2 Inc. http://wso2.com >>>>> >>> lean . enterprise . middleware >>>>> >>> >>>>> >>> cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >>>>> >>> twitter: http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> 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 >>>>> >> >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Architecture mailing list >>>>> > [email protected] >>>>> > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> ============================ >>>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>>>> Site: http://home.apache.org/~hemapani/ >>>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>> Phone: 0772360902 >>>> >>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Technical Lead - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 >>> >>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Technical Lead - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> >> -- >> Sachith Withana >> Software Engineer; WSO2 Inc.; http://wso2.com >> E-mail: sachith AT wso2.com >> M: +94715518127 >> Linked-In: https://lk.linkedin.com/in/sachithwithana > > > > > -- > ============================ > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://home.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 -- ============================ Blog: http://srinathsview.blogspot.com twitter:@srinath_perera Site: http://home.apache.org/~hemapani/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
