Hi Frank, I agree on your concerns.
However, reason we are though of doing this is relationship between data item and a user is not 1-1, but rather complicated. e.g. 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. Above transaction is owned by all three users: Bob, Alice, and Charlie. It is complicated to match this to a permission model. We felt you need to understand the context of the data generated and used ( e.g. above API manager scenario) to decide how to do access control. Scenario will be very different with IoT as involved roles will be different so on and so forth. If there is an efficient way to generalize and map permissions, we can go with that. We felt it is complicated to solve. --Srinath On Thu, Mar 31, 2016 at 4:38 PM, Frank Leymann <fr...@wso2.com> wrote: > Sorry for jumping into the discussion late (or even too late). I try to > understand the discussion by drawing analogies to DBMS - maybe that's wrong > and I miss the point... If I am right, what you decided in the meeting is > fully in line with what DBMS are doing :-) > > In Srinath's summary, list item (2): The API then actually will be in > charge of implementing access control. Because the API needs to decide who > can see which data. Writing an API accessing data is like writing a SQL > program accessing a database. Then, we are asking an SQL program to > implement access control by itself, isn't it? This is cumbersome, and > likely each product has to implement very similar mechanisms. > > In Srinath's summary, list item (1): This sounds like established practice > in DBMS. When a SQL programmer writes a program, she must have all the > access control rights to access the DBMS. The final program is than subject > to access control mechanism w.r.t. to the users of the program: whoever is > allowed to use the program somehow inherits the access writes of the > programmer (but only in context of this program). When identifying the SQL > programmer with the tenant (or tenant admin), this is what (1) of the > summary decided, correct? > > From Srinath's summary: "*Also this means, we will not support users > providing their own analytics queries. Only tenant admins can provide > their own queries.*" Again, identifying tenant admins with SQL > programmers, that's exactly the paradigm. > > > Best regards, > Frank > > 2016-03-31 10:32 GMT+02:00 Srinath Perera <srin...@wso2.com>: > >> 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 <srin...@wso2.com> >> wrote: >> > >> > I have scheduled a meeting tomorrow to discuss this. >> > >> > --Srinath >> > >> > On Tue, Mar 29, 2016 at 11:44 AM, Sachith Withana <sach...@wso2.com> >> 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 <nuw...@wso2.com> wrote: >> >>> >> >>> Please ignore my reply. It was intended for another thread :) >> >>> >> >>> On Mon, Mar 28, 2016 at 4:26 PM, Nuwan Dias <nuw...@wso2.com> 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 <srin...@wso2.com> >> 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 <ayy...@wso2.com> >> 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: ayy...@wso2.com cell: +94 77 1681010 >> >>>>> > >> >>>>> > On Sat, Mar 26, 2016 at 1:03 AM, Ruwan Yatawara <ruw...@wso2.com> >> 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 : ruw...@wso2.com >> >>>>> >> mobile : +94 77 9110413 >> >>>>> >> blog : http://ruwansrants.blogspot.com/ >> >>>>> >> www: :http://wso2.com >> >>>>> >> >> >>>>> >> >> >>>>> >> On Fri, Mar 25, 2016 at 11:55 PM, Sriskandarajah Suhothayan < >> s...@wso2.com> 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 < >> srin...@wso2.com> 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 >> >>>>> >>> Architecture@wso2.org >> >>>>> >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >>>>> >>> >> >>>>> >> >> >>>>> >> >> >>>>> >> _______________________________________________ >> >>>>> >> Architecture mailing list >> >>>>> >> Architecture@wso2.org >> >>>>> >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >>>>> >> >> >>>>> > >> >>>>> > >> >>>>> > _______________________________________________ >> >>>>> > Architecture mailing list >> >>>>> > Architecture@wso2.org >> >>>>> > 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 : nuw...@wso2.com >> >>>> Phone : +94 777 775 729 >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nuwan Dias >> >>> >> >>> Technical Lead - WSO2, Inc. http://wso2.com >> >>> email : nuw...@wso2.com >> >>> Phone : +94 777 775 729 >> >>> >> >>> _______________________________________________ >> >>> Architecture mailing list >> >>> Architecture@wso2.org >> >>> 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 >> Architecture@wso2.org >> 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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
