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; ext: 51736*; *M: +44 782 741 1966Linked-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
