none
Security trimming for FAST search using Query Object Model RRS feed

  • Question

  • We have a WCF search application that contacts FAST search through SharePoint Query Object Model to fetch results from FAST Server for SharePoint 2010. The search application will pass the details of user (like Domain Name and UserName) who is performing the search. The results returned by the WCF service must be trimmed as per the access rights ( of the user who is performing search. In short, we need to programmatically perform security trimming on FAST using SharePoint Query Object Model. We are unable to find any articles or examples for this in the internet. Please guide
    Friday, April 22, 2011 2:41 PM

All replies

  • Custom security trimming is not possible with the current version of Fast Search Server.
    Friday, April 22, 2011 5:58 PM
  • It is not clear what kind of security the data being indexed has. If the data has AD or SharePoint security, and the calling application is running under the credentials of a user in this AD, then it should work automatically.

    If the call to search.asmx provides the credentials of a valid AD user, then this users context will be used on the executing call. Since it's an application I assume it will already run with the logged on users credentials, and you would only have to supply the DefaultNetworkCredentials on the WCF call, in order to get it to work.

    Depending on how you have added the reference to search.asmx, there are different ways of adding the users credentials to the call.

    Typically it would be something like:

    QueryServiceSoap.QueryServiceSoapClient client = new QueryServiceSoap.QueryServiceSoapClient();
    client.ClientCredentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
    client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
    

    where you would use TransportSecurityOnly and NTLM.

    If the above matches your scenario there is no need for custom security trimming.

    Regards,
    Mikael Svenson 


    Search Enthusiast - MCTS SharePoint/WCF4/ASP.Net4
    http://techmikael.blogspot.com/ - http://www.comperiosearch.com/
    Friday, April 22, 2011 9:03 PM
  • Thanks Mikael for the quick reply.

    The data gets indexed using AD and Sharepoint security context only. However, we are using Query Object Model (Microsoft.office.server.search.query namespace) and not the query web service. So we need to know how to impersonate the credentials using the query object model. Also, by default, the client application will call the WCF using its own credentials and anonymous search must also be performed. But when the client application passes the User Name and Domain name information, we need to perform security trimming with these credentials. Any ideas on this?

    Monday, April 25, 2011 6:39 AM
  • Is your setup something like this:

    [SharePoint 2010/FAST] <-> [WCF Service using Client Object Model] <-> [Client application]

    And is the WCF service hosted inside or outside of SharePoint?

    If the WCF service is hosted outside of SharePoint, then the client app will run as the appropriate user, and you want the credentials to carry over to the WCF app, in order for the correct security trimming to work. This is called "delegation" of identiy. You can find more information on delegation and impersonation at MSDN. If it's hosted inside of SharePoint, then it's a matter of setting an impersonation context around the search call. Let me know your scenario and I can test it out.

    The easy option would be to use the search webservice directly from end user client :)

    Your problem is not FAST/SharePoint security trimming per say, but how to make the call go over to SharePoint as the end user. The same would apply to any other SharePoint call you make in the same fashion as the Query Object Model.

    Regards,
    Mikael Svenson 


    Search Enthusiast - MCTS SharePoint/WCF4/ASP.Net4
    http://techmikael.blogspot.com/ - http://www.comperiosearch.com/
    Monday, April 25, 2011 7:00 PM
  • Mikael,

     

    Yes. The setup is exactly the same. Just one correction. It is not WCF service using Client Object Model. It is WCF service using Query Object Model. Also, the WCF service is hosted inside of SharePoint. So we pretty much need to set the impersonation context around the search call! There is one catch though. By default, security context of the account under which the client application runs will be passed to the WCF service and not the context of the user who logged in to the client application. So if the client application also passes the details of the user name and domain under which the search must be performed, only then we need to use this information( AD user name and domain name) and make the call to FAST suitably. (If my understanding is correct, we have to supply the user details to SearchServiceApplicationProxy so that it can contact STS to generate the correct SAML token.) Hope this explains the scenario clearly.

    Tuesday, April 26, 2011 3:07 PM
  • I did mean Query Object Model. Typing error :)

    You are mistaken on what credentials are passed along as default on the WCF call. Default, no credentials are passed, you have to add them specifically via code or configuration as I wrote in my first post.

    From what you write it seems the client app is a web app, running as some user? And I assume the web app uses windows authentication. If so, you could add 

    <system.web> <identity impersonate="true" /> </system.web>
    

    to your web.config, and the DefaultNetworkCredentials should be that of the logged in user.

    Also, what kind of security are you using for sharepoint, forms, windows, claims? All questions I should have asked in the first post :)

    I guess this thread should be moved to the SP2010 general forum as well.

    Regards,
    -m 


    Search Enthusiast - MCTS SharePoint/WCF4/ASP.Net4
    http://techmikael.blogspot.com/ - http://www.comperiosearch.com/
    Tuesday, April 26, 2011 7:25 PM
  • We are not using SharePoint security. We have just included the sharepoint related namespaces as references in the WCF service. WCF service is using windows authentication. We tried impersonating the client application with credentials of different users but when we check the FAST query log, we find that the security trimming is being performed with the same UID token like this 'qtf_securityfql:uid=MCMud3x1c1xwdXNkcGRrYXJuYX' . I mean the value of this UID field is the same for all the users impersonating the call made by the client application. Please let me know if you know if you have an alternate solution. Please note that when we change the app pool id under which the WCF service runs, the value of the qtf security id changes. (in other words the qtf id is dependent only on the app pool id)

    Monday, May 2, 2011 2:05 PM
  • Hi Pavan,

    and hence you are executing the call as the AppPool user, and not the user connecting to your service.

    I will see if I have time to create an example this week on how to do this in your scenario, but I'm a bit busy this week teaching a FAST for SharePoint workshop.

    Feel free to e-mail me a test WCF service and user-client so I see your code and configs. miksvenson at gmail.com.

    Regards,
    Mikael 


    Search Enthusiast - MCTS SharePoint/WCF4/ASP.Net4
    http://techmikael.blogspot.com/ - http://www.comperiosearch.com/
    Monday, May 2, 2011 6:26 PM
  • Hi Mikael,

     

    We have achieved it by using programmatic impersonation. I have impersonated the complete QOM call and verified QR server logs for correctness of user token.

    It is working fine.

     

    Thanks for your help.

     

    -Pavan

    Wednesday, May 25, 2011 1:48 PM
  • I actually did this myself the other day for a solution I was building, but I forgot about your question. Glad you worked it out :)

    -m


    Search Enthusiast - MCTS SharePoint/WCF4/ASP.Net4
    http://techmikael.blogspot.com/
    Wednesday, May 25, 2011 2:39 PM
  • I solved it by doing impersonation using a trusted service account. See my post - http://vishalseth.com/post/2013/11/05/Impersonated-Searching-against-SharePoint.aspx
    Tuesday, November 5, 2013 10:46 PM