Hi Senaka, Not actually the user permissions. we are storing the resource permissions. We are storing allowed roles for the given resource with the other resource data in the file system(solr). So that we can filter the assets against the roles of the logged in user directly from solr.
lets says, we have a resource which is allowed only for "admin", "internal/everyone" to read that asset. those two roles are also going to store against that resource in solr. So if a user with admin role search for that resource, we can get the results directly from the solr search. And also this will an internal logic executed for every resource and cannot be changed with any extension point. We are not exposing any role details with the search results. Thanks Danesh On Tue, Jan 26, 2016 at 12:39 PM, Senaka Fernando <[email protected]> wrote: > Alright. > > So, do we store user permissions on the file system and in a way that > someone external can manipulate them? > > Also, is it per user stuff that we store or per role stuff? > > And, what if 10 ppl search at the same time? > > Thanks, > Senaka > > On Tuesday, 26 January 2016, Danesh Kuruppu <[email protected]> wrote: > >> Hi Susinda, >> >> We are indexing all permission changes done for the resource.(add new >> permissions, edit permissions, remove permissions etc). Any changes done >> for user level will be track when searching the resource. we are getting >> the user roles of the logged in user when searching the resource. >> >> Thanks >> Danesh >> >> On Tue, Jan 26, 2016 at 10:28 AM, Susinda Perera <[email protected]> >> wrote: >> >>> >>> >>> On Tue, Jan 26, 2016 at 8:32 AM, Chandana Napagoda <[email protected]> >>> wrote: >>> >>>> Hi Senaka, >>>> >>>> Here we are providing resource authorization information into Solr . So >>>> when the user is performing search operation, we are adding user roles as >>>> Solr query parameter. Then Solr search result contains the resource paths >>>> which are visible to the user who is performing search operation. Here we >>>> are not implementing any resource authorization level caching mechanism and >>>> just allow Solr to do the search operation based on the user role. If there >>>> are any resource level authorization changes, >>>> >>> How do we track the changes or role deletion/adding? >>> >>>> we are re-indexing the resource with new changes. Further with this >>>> improvement, we can do pagination from the Solr level. >>>> >>>> Regards, >>>> Chandana >>>> >>>> On Tue, Jan 26, 2016 at 4:41 AM, Senaka Fernando <[email protected]> >>>> wrote: >>>> >>>>> Hi Danesh, >>>>> >>>>> Hang-on. So, you check authorizations once and forall? and then cache >>>>> it? If so, is it @ a user-level or a role-level? >>>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> On Mon, Jan 25, 2016 at 1:30 PM, Danesh Kuruppu <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> [+] Senaka. >>>>>> >>>>>> We tested the above fix with 3000 assets (wsdl - 32, wadl - 08, >>>>>> soapservice - 2040, restservice - 1040, schema - 27, endpoints -49, >>>>>> policies - 06, swagger - 06). Following time taken to load the anonymous >>>>>> view of Store view with and without the fix. >>>>>> >>>>>> *Without the fix,* >>>>>> * First call - 304874ms >>>>>> * Second call - 2429ms (with cache) >>>>>> >>>>>> *With the fix,* >>>>>> * First call - 1798ms >>>>>> * Second call - 617ms (with cache) >>>>>> >>>>>> According to the results, There is huge performance improvement with >>>>>> the fix. This is because, with the fix we are not doing any external >>>>>> calls(authorization calls) to get the authorized asset list of the user. >>>>>> We >>>>>> are getting this from the indexed data as discussed earlier. >>>>>> >>>>>> Thanks >>>>>> Danesh >>>>>> >>>>>> On Sat, Jan 23, 2016 at 6:19 PM, Danesh Kuruppu <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> As per the discussion we(Sagara, Chandana, Isuruwan, SameeraM, >>>>>>> Danesh) had last week, we came up with following suggestions. >>>>>>> >>>>>>> 1. Bind allowed roles of the resource with the indexed document. >>>>>>> Here we are adding new multivalued string field for every indexed >>>>>>> document >>>>>>> which contains allowed roles of the resource. for example, if the >>>>>>> resource >>>>>>> have allowed for "admin", >>>>>>> "internal/everyone","internal/publisher","system//wso2.anonymous.role", >>>>>>> >>>>>>>> "allowedRoles_ss": [ >>>>>>>> "admin", >>>>>>>> "internal/everyone", >>>>>>>> "internal/publisher", >>>>>>>> "system/wso2.anonymous.role" >>>>>>>> ], >>>>>>>> >>>>>>>> 2. Add additional filter query for all search queries to filter the >>>>>>> resources based on user roles. Here we are adding new filter query with >>>>>>> assigned roles of the logged in user. for example, if the logged in >>>>>>> user is >>>>>>> assigned to "Internal/everyone" and "admin" >>>>>>> >>>>>>> allowedRoles_ss:Internal/everyone *OR* admin >>>>>>> >>>>>>> >>>>>>> 3. Use solr based pagination and sorting for registry searching. >>>>>>> >>>>>>> Please add your suggestions on this. >>>>>>> And also, I have done the initial implementation with above >>>>>>> suggestions. Shall we have a review next week. >>>>>>> >>>>>>> Thanks >>>>>>> Danesh >>>>>>> >>>>>>> On Thu, Jan 14, 2016 at 6:57 AM, Danesh Kuruppu <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Problem: >>>>>>>> Asset listing page loading in anonymous view takes considerably >>>>>>>> lots of time, If there are many assets in the system, but there are >>>>>>>> only >>>>>>>> few or no public assets(public assets count < search limit). Loading >>>>>>>> time >>>>>>>> will increase with the total assets count. >>>>>>>> >>>>>>>> Reason: >>>>>>>> In registry search implementation, we are iterating search >>>>>>>> results(total assets) till we get the authorized assets list(list of >>>>>>>> assets >>>>>>>> which are authorized to view for the user) count to certain limit(This >>>>>>>> limit is varying with the user case, can be defined in query time). >>>>>>>> but if >>>>>>>> the logged in user (or anonymous user in public view) doesn't have >>>>>>>> enough >>>>>>>> assets(authorized assets < defined limit) to view, we have to iterate >>>>>>>> all >>>>>>>> the assets and check the authorization to get the final asset count for >>>>>>>> that user. >>>>>>>> >>>>>>>> e.g: >>>>>>>> Lets say we have 1000 total assets in the system. In our search >>>>>>>> query, we have set the limit to get 10 assets. In our search impl, we >>>>>>>> are >>>>>>>> iterating through assets(1000) and checking authorization for each >>>>>>>> asset >>>>>>>> till we get the authorized list count equals to our limit(10). Once we >>>>>>>> get >>>>>>>> the required asset count, we stop checking and return the asset list. >>>>>>>> If a >>>>>>>> user authorize only to view 05 assets in the system (user doesn't have >>>>>>>> enough assets to view), we have to iterate through all assets(1000) to >>>>>>>> the >>>>>>>> final count as 05. >>>>>>>> >>>>>>>> This authorization check is an expensive operation. Since we need >>>>>>>> to get this information from external user store(database, ldap etc). >>>>>>>> Sometime this call takes couple of seconds and it depends network >>>>>>>> latency >>>>>>>> etc. So if there are lots of assets, System takes lots of time to load >>>>>>>> asset listing page. >>>>>>>> >>>>>>>> Currently we don't have a solution for this issue. According to the >>>>>>>> solr, one way is to bind the access control list(user roles list) with >>>>>>>> the >>>>>>>> document in indexed data and pass user role id with the search query. >>>>>>>> Please refer [1][2]. But this will not work for us, since we are >>>>>>>> managing >>>>>>>> permission for each role separately. >>>>>>>> >>>>>>>> Your suggestions on this please. We need to come up better solution >>>>>>>> to fix this issue. >>>>>>>> >>>>>>>> 1. >>>>>>>> http://www.slideshare.net/lucenerevolution/pdf-lucene-solrrevdocumentlevelsecurityrajanimaskifinal >>>>>>>> 2. >>>>>>>> https://lucidworks.com/blog/2015/05/15/custom-security-filtering-solr-5/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> -- >>>>>>>> >>>>>>>> Danesh Kuruppu >>>>>>>> Software Engineer >>>>>>>> WSO2 Inc, >>>>>>>> Mobile: +94 (77) 1690552 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Danesh Kuruppu >>>>>>> Software Engineer >>>>>>> WSO2 Inc, >>>>>>> Mobile: +94 (77) 1690552 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Danesh Kuruppu >>>>>> Software Engineer >>>>>> WSO2 Inc, >>>>>> Mobile: +94 (77) 1690552 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* >>>>> Solutions Architect; WSO2 Inc.; http://wso2.com >>>>> >>>>> >>>>> >>>>> *Member; Apache Software Foundation; http://apache.org >>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: >>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>> >>>>> >>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: >>>>> http://linkedin.com/in/senakafernando >>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> *Chandana Napagoda* >>>> Senior Software Engineer >>>> WSO2 Inc. - http://wso2.org >>>> >>>> *Email : [email protected]**Mobile : +94718169299 <%2B94718169299>* >>>> >>>> *Blog : http://cnapagoda.blogspot.com >>>> <http://cnapagoda.blogspot.com>* >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *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 >>> >>> >> >> >> -- >> >> Danesh Kuruppu >> Software Engineer >> WSO2 Inc, >> Mobile: +94 (77) 1690552 >> > > > -- > > > *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* > Solutions Architect; WSO2 Inc.; http://wso2.com > > > > *Member; Apache Software Foundation; http://apache.org > <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 > 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; > > > *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: > http://linkedin.com/in/senakafernando > <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Danesh Kuruppu Software Engineer WSO2 Inc, Mobile: +94 (77) 1690552
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
