Search in SharePoint 2013 performs query-time security trimming of search results right out of the box and you can develop your own custom security trimming if the out of box trimming does not suffice. Using search you can leverage the index that is built in the background using continuous crawl. You can use Search as a security trimmed data source to build your portal navigation system, especially if you have a complex site structure. We get major performance improvements from using the security trimmed search API for navigation, this will speed up page loading and almost eliminate SQL calls because there are no heavy content queries across multiple nested sites.
In this example you can use Search API to return a list of sites and or sub sites (webs), and this list would be security trimmed based on who is executing the query against the index . To return site and sub sites listing we use of the contentclass managed property available out of box without configuring or custom code. Managed properties are generated by Search, thus structuring the Index so we can specify SQL like select and where clauses so we can extract exactly what we need, similar to how one would query an SQL database. You just have to know what value to specify as your managed property. To return a list of all sites and sub sites in the search index, we specify a value of STS_Site (managed property). Here is what a query might look like. http://yoursite.com/anysite/_api/search/query?querytext=’contentclass:sts_site’
Try it out in your browser, just change the URL and site path, it will return the list that you have access to right before your eyes, or even easier copy and paste the portion to the right of the question mark into any Search box on your Search Site. Here is another example to further control what is returned out of the index. http://yoursite.com/anysite/_api/search/query?querytext=’contentclass:STS_Web’&’trimduplicates=false’&’rowlimit=300
There is an article here showing you some common managed properties you can use in your queries to further restrict the returned results.. http://knowspswss.blogspot.ca/2012/10/sharepoint-using-content-class-property.html
So by now you may be asking yourself how can I use all this in my Portal page to show and hide information based on the security model. First you need governance in place, you need to create sites and sub sites per your organizational structure and grant or deny access to users per an approved and well known model. This site structure can be hierarchical or flat, in other words it does not matter if you create many sub sites under site collections or if you have a flat (non-hierarchical) set of sites. Once this is in place the query described above will return a predictable security trimmed site listing. The major win here is reuse, secure sites once, then reuse that security in your Portal for free.
Please take a look at the code in the github link at line 31, “success: Results.onSuccess”, at this point you could insert your own function code with a series of “if” statements to show or hide data. For example lets say your portal page has 10 areas or pieces of content that would need to be hidden based on the security model, start a loop through the results, if the site exists, show the content, if site does not exist, hide content. Any anonymous content, which can be seen by anyone, would fall outside the loop and always show.