Gravatar for george.chang@perficient.com

Question by georgechang, Jan 4, 2016 11:35 AM

Late Binding Not Executing Without Indexed Permissions

We're working on an issue with using late binding on a source where if you use late binding with a custom security provider without any indexed permissions, the security provider AuthorizeUser method never gets executed and returns no results. However, if you switch the permissions to use "Specifies the security permissions to index", then index the username with the results, then flip it back to "Late Binding", the AuthorizeUser does get called and the username is still indexed. We can't index/specify every single user name nor does the security paradigm support groups (no "everyone"). Is there a way around this where we can execute the late binding without any indexed permissions?

Gravatar for slangevin@coveo.com

Comment by Simon, Jan 4, 2016 1:53 PM

Hi, what connector is this? I know the provider is custom but I would like to know the connector , is it also custom?

Gravatar for george.chang@perficient.com

Comment by georgechang, Jan 4, 2016 1:55 PM

This is using the free edition of Coveo for Sitecore (queue connector).

Gravatar for slangevin@coveo.com

Comment by Simon, Jan 5, 2016 3:30 PM

What is the Business case for the late binding? To be honest, this has not been used for a long time. Any reason to bypass the early binding?

Gravatar for george.chang@perficient.com

Comment by georgechang, Jan 5, 2016 3:32 PM

Yes, unfortunately, the way that the custom security works for the application requires a late binding approach. The security is handled by a web service that is called at query time to trim the result set.

Gravatar for slangevin@coveo.com

Comment by Simon, Jan 5, 2016 4:29 PM

What is the supported SecurityType? Is the identity doing the search (Captured in the CES Console) the one you are expecting?

Gravatar for george.chang@perficient.com

Comment by georgechang, Jan 5, 2016 4:36 PM

Yes, the identity is correct. Everything works correctly if I add the user and index it (including hitting the custom security provider) but if there are no permissions are indexed, it never hits the custom security provider at all.

Gravatar for slangevin@coveo.com

Comment by Simon, Jan 6, 2016 9:25 AM

I guess you will have to push the user identity to the index. Using the REST API, here is one way to do it: https://developers.coveo.com/display/public/SearchREST/Overriding+User+Ids

Gravatar for george.chang@perficient.com

Comment by georgechang, Jan 7, 2016 9:57 AM

I've added another user identity to the array with the HttpHandler and it seems to be working properly now. The only thing that is still questionable are the item counts for the facets - they seems to still be displaying the pre-authorized counts instead of the security trimmed counts.

Gravatar for jflheureux@coveo.com

Comment by Jean-François L'Heureux, Jan 7, 2016 5:29 PM

For the facet counts, this is unfortunately a limitation of late binding.

Let's say a user does a query and asks for the first 10 results matching his query.

In late binding mode, the index filters the indexed documents with the query terms. Let's say there's 2000 documents matching the query. Then, it needs to ask to the security provider whether the user have access to the first 10 documents. That is minimum 10 calls to the security provider to build the returned search result. After identifying the 10 search results, the index stops there because it would be very long to call the security provider for all the remaining 1990 documents. The result count returned will be 2000 minus the number of access denied responses received from the security provider.

To determine the facet values and their occurrences, the index loads the values of the first 1000 (configurable) documents matching the query to build the facet values array. Then, for each unique facet value, it counts the occurrences in the results matching the query (2000 in this case). Imagine if the index would have to ask the security provider if the user have access to all those documents. It would be very very slow.

Other things that may not be 100% accurate in late binding:

  • Results count (because security is resolved only for the first X results until the number of results asked are identified)
  • Ranking in general (because the longest ranking algorithms evaluate only the first hundreds of search results, which could be all access denied by your security provider, so the remaining search results have less ranking logic applied to)

I hope it clarifies the usage of late binding. It is not an ideal solution but seems to be the only one due to your project's constraints.

0 Reply
Ask a question