Hi Manu, Please find my inline comments.
Action namespaces > We have namespaced the permission by the “protocol” of the resource URI. > Then, do we need to namespace the actions as well? topoic:view, api:view, > dashboard:view has almost the semantic. Having it just as “view” will be > useful when we want to use the same code or same lifecycle xml to govern > them. Because unlike resource URI, which are just arbitrary strings, > semantic of these words are understood by the code/ lifecycle xml. Action namespaces won't make any sense in somecases. But namespaces can derive the scope of the action. For instance; consider a scenario we have a resource on registry path system/governance/security/*. Same resource is accessible through web and mqtt. When we need to allow user to access this resource only through the web. We can define it as *reg*: system/governance/security/*:[*web:view].* Thanks, Rasika On Thu, Jul 14, 2016 at 8:40 PM, SajithAR Ariyarathna <[email protected]> wrote: > Hi Manu, > > >> Permissions for UI pages >> I think there is no need to introduce a separate permission namespace for >> UI (or use a very limited one). Actual customer is concerned about giving >> permission to a real resource (topic, API, proxy ...) not to a UI >> URL. Ideally, for each page, we associate the page with an existing >> permission space using a URI pattern mapping. >> > +1. We can derive the permission of a web page (URL) from the resource/s > that are associated with/shown in that page. Until we encounter a situation > where we cannot derive permission of the URL (any examples?), let's use > existing permissions. > > Thanks > > > > On Thu, Jul 14, 2016 at 8:18 PM, Manuranga Perera <[email protected]> wrote: > >> Following are few questions I have on C5 permission model. Answers may >> have already been discussed, and I might have missed. If so, shall we get >> them on mail. >> >> Action namespaces >> We have namespaced the permission by the “protocol” of the resource URI. >> Then, do we need to namespace the actions as well? topoic:view, api:view, >> dashboard:view has almost the semantic. Having it just as “view” will be >> useful when we want to use the same code or same lifecycle xml to govern >> them. Because unlike resource URI, which are just arbitrary strings, >> semantic of these words are understood by the code/ lifecycle xml. >> >> Permissions for UI pages >> I think there is no need to introduce a separate permission namespace for >> UI (or use a very limited one). Actual customer is concerned about giving >> permission to a real resource (topic, API, proxy ...) not to a UI >> URL. Ideally, for each page, we associate the page with an existing >> permission space using a URI pattern mapping. >> >> Eg: Let’s assume >> http://mb.cloud.wso2.com/mb-explorer/topics/petNews/catNews has to be >> associated with {jms://petNews/catNews, jms.view } >> And for this we may introduce following UUF directive to the page >> >> In ./pages/topics/{+topicPath}.hbs file >> … >> {{secure “jms://{topicPath}” ”jms:view”}} >> <html> >> <h1>Info about the topic: {{topicPath}}<h2> >> … >> >> Getting paginated list of resources >> Following performance issue will occur when we try to obtain a paginated >> resource list (Greg/Store artifices, DAS rows?) view for a given user. Lets >> assume we need to show first 10 store artifacts (eg: APIs) in UI / or >> through API. To archive this we get the first 10 resource, and then filter >> it by permission in Java by iterating each. Assume out of that 10, the user >> can only see 4, then we need to get next 10 and filter and next 10 … >> >> Now assume we need to show the last 10 resources in UI. This is even >> worse. In current GReg with LDAP this will take about 10min if we have 8000 >> resources regardless of the user (last time I checked). Hypothetically, if >> we have a JDBC user store and the resource are in the same DB, this is a >> single join query. Obviously, this will not work in a real world case since >> permission are in different place. >> >> Perhaps we can use Lucene indexing? But how do we invalidate the indexer >> cache? >> >> Criteria for using to Group vs Role >> Currently we have associated everything with a role, in C5 some should >> become groups and others should become groups. >> >> Eg: Currently in dashboard server, any given dashboard can be associated >> with any role via UI, and only that role (and admins) will be able to see >> it. In C5 should dashboard will have a permission >> {dashboard://xyz-cxo-dahboard,dashboard:view}. Then in UI should we give >> the ability to associate it with a Role or Group? >> >> (I personally don’t see the point of having two concepts, but if we do, >> we should have a clear guideline when to use which) >> >> Code duplication due to un-polymorphic Group and Role >> >> Group class and the Role class share lot of method signatures but there >> is no common interface both implements. Therefore, devs may have to repeat >> code sections for each by copy-pasting, not using proper polymorphism. Eg: >> UI for adding users to a Role/Group cannot share same code. >> >> Maybe this kind of code is rare, is it? If so we can ignore this. >> >> -- >> With regards, >> *Manu*ranga Perera. >> >> phone : 071 7 70 20 50 >> mail : [email protected] >> > > > > -- > Sajith Janaprasad Ariyarathna > Software Engineer; WSO2, Inc.; http://wso2.com/ > -- With Regards, *Rasika Perera* Software Engineer M: +94 71 680 9060 E: [email protected] LinkedIn: http://lk.linkedin.com/in/rasika90 WSO2 Inc. www.wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
