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] <[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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
