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
