This blog post will show you how to write your own custom security post-trimmer for SharePoint 2013. Not only that, we will take you through the steps of deploying and registering the trimmer using a crawl rule before putting the trimmer to work.

Why Post-Security Trimming

There are two kinds of custom security trimming: Pre-trimming refers to pre-query evaluation where the backend rewrites the query adding security information before the index lookup in the search index. Post-trimming refers to post-query evaluation where the search results are pruned before they are returned to the user.

Post-trimming analyzes each search result after the query has been evaluated. Performance and potential incorrect refiner data and hit counts aside, sometimes it is necessary to perform last-minute security evaluation "when the results are served".

One scenario could be to deny documents in the search results for machines that do not have proper anti-virus software. Another can be to restrict certain documents from being visible in the search results outside a given time of day.

Requirements

• SharePoint 2013 Server
• Visual Studio 2012
• A Custom Connector sending claims (see previous post on this blog).

The Trimmer Design

Let's create a simple post-security trimmer. It should remove documents from the search results if a certain hint is given for document results. We will use the string field docaclmeta for this purpose. The rules are simple. Documents will be removed if this field contains the text 'deny'. If this field is empty or contains anything else (e.g. 'allow'), then the documents will be visible in the search results.

The Code

This MSDN article offers useful starting tips on creating the security post-trimmer project in Visual Studio, adding the references to both the Microsoft.Office.Server.Search.dll and the Microsoft.IdentityModel.dll.

The following is added to the using directives at the beginning of the class file, SearchPostTrimmer.cs:

    using System.Collections.Specialized;
    using System.Security.Principal;
    using Microsoft.Office.Server.Search.Administration;
    using Microsoft.Office.Server.Search.Query;

We then define the class as implementing the ISecurityTrimmerPost interface in the class declaration:

public class SearchPostTrimmer : ISecurityTrimmerPost

We do not need any additional settings for this trimmer to work. Thus, the Initialize method remains empty:

    /// <summary>
    /// Initialize the post-trimmer.
    /// </summary>
    /// <param name="staticProperties">Static properties configured for the trimmer.</param>
    /// <param name="searchApplication">Search Service Application object</param>
    public void Initialize(NameValueCollection staticProperties, SearchServiceApplication searchApplication)
    {
        // Intentionally blank
    }    

The actual trimmer logic resides in the CheckAccess method. This method returns a bit array with values 1 or 0, grant access or deny access, respectively.

We will check for the term 'deny' in document's docaclmeta field. If so, we will remove that document from the search results.

    /// <summary> 
    /// Check access for the results returned from the search engine
    /// </summary>
    /// <param name="documentUrls"> List of the URLs for each document whose access is to be determined by the security trimmer implementation.</param>
    /// <param name="documentAcls"> List of the document ACLs for each document whose access is to be determined by the security trimmer implementation. This list may be null or may contain String.Empty strings.</param>
    /// <param name="sessionProperties"> Transient property bag valid within the scope of a single query processing component execution.</param>
    /// <param name="userIdentity"> Identity of the user.</param>
    /// <returns>a bitarray with values 1 if the respective document identifier from documentUrls has been granted access or 0 if the respective document identifier has not been granted access </returns>
    public BitArray CheckAccess(
        IList<string> documentUrls, 
        IList<string> documentAcls, 
        IDictionary<string, object> sessionProperties,
        IIdentity passedUserIdentity)
    {
        if ((null == documentCrawlUrls) || (documentCrawlUrls.Count < 1))
        {
            throw new NullReferenceException("Error: CheckAccess method is called with invalid URL list");
        }

        if ((null == documentAcls) || (documentAcls.Count < 1))
        {
            throw new NullReferenceException("Error: CheckAccess method is called with invalid ACL list");
        }

        if (null == passedUserIdentity)
        {
            throw new NullReferenceException("Error: CheckAccess method is called with invalid user identity parameter");
        }
        
        // Initialize the bit array with false value which means all results will be trimmed out.
        var urlStatusArray = new BitArray(documentCrawlUrls.Count, false);
        for (var x = 0; x < documentAcls.Count; x++)
        {
            if (!string.IsNullOrEmpty(documentAcls[x]))
            {
                urlStatusArray[x] = true;
                if (string.Compare(documentAcls[x], "deny", StringComparison.InvariantCultureIgnoreCase) == 0)
                {
                    urlStatusArray[x] = false;
                }
            }
            else
            {
                urlStatusArray[x] = true;
            }
        }

        return urlStatusArray;
    }

Performance Considerations 

One might consider the following tips to improve the overall performance with this trimmer as a starting point:

• Use Pre-Security trimming instead for improved performance and correctness (hit counts etc.)
• Cache locally any data needed to evaluate if a result should be removed or not

Deploying Trimmer

After you have built the custom security trimmer project, you must deploy it to the global assembly cache on any server in the Query role.

1. On the Start menu, choose All Programs, choose Microsoft Visual Studio 2010, and then choose Visual Studio Tools and open a Visual Studio command prompt.
2. To install the SearchPostTrimmer.dll, type the following the command prompt
   
   gacutil /i <ExtractedFolderPath>\PostTrimmer\bin\Debug\SearchPostTrimmer.dll
3. As the last step of deploying the trimmer, we need to learn about the token of the DLL. Type the following the command prompt
   
   gacutil /l SearchPostTrimmer
   Write down the token listed for the newly added DLL.

Registering Trimmer

1. Open the SharePoint Management Shell.
2. At the command prompt, type the following command:
   
   New-SPEnterpriseSearchSecurityTrimmer -SearchApplication "Search Service Application"
   -typeName "CstSearchPostTrimmer.SearchPostTrimmer, CstSearchPostTrimmer,
   Version=1.0.0.0, Culture=neutral, PublicKeyToken=token" -RulePath "xmldoc://*"
   
   where token is the text copied from the gacutil /l command above. The xmldoc://* refers to the crawl rule we defined in the XML Connector blog post. Example: New-SPEnterpriseSearchSecurityTrimmer -SearchApplication "Search Service Application" -typeName "CstSearchPostTrimmer.SearchPostTrimmer, SearchPostTrimmer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4ba2b4aceeb50e6d" -RulePath "xmldoc://*" -Id 1
3. Restart the Search Service by typing
   
   net restart sphostcontrollerservice

Testing the Trimmer

Now, you can issue queries and the beauty of the Post-trimmer logic should reveal itself on each query evaluated. Try modifying the docaclmeta field contents in the Product.xml file for the custom connector, issue a full crawl and repeat the query.

Acknowledgements

Author: Sveinar Rasmussen (sveinar).

https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-55-87-Trimming/8512.PostTrimmer.zip

This blog post will show you how to write your own custom security pre-trimmer for SharePoint 2013. We will take you through the steps of deploying and registering the trimmer before putting the trimmer to work.

Why Use Pre-Security Trimmers

Pre-trimming refers to pre-query evaluation where the backend rewrites the query adding security information before the index lookup in the search index. Post-trimming refers to post-query evaluation where search results are pruned before they are returned to the user.

We recommend the use of pre-trimming for performance and general correctness; pre-trimming prevents information leakage for refiner data and hit count instances.

Requirements

• SharePoint 2013 Server
• Visual Studio 2012
• A Custom Connector sending claims (see previous post on this blog)

The Trimmer Design

Let's create a simple pre-security trimmer. A trimmer that reads group membership data from a text file, performs a user lookup for group membership data and then adds claims to the query tree based upon this. In short, the trimmer code needs to figure out which user that is issuing the query, then perform a group membership lookup on that user and then add claims for that user, depending on the group membership.

The Code

This MSDN article offers useful starting tips on creating the security pre-trimmer project in Visual Studio, by adding references to both the Microsoft.Office.Server.Search.dll and the Microsoft.IdentityModel.dll.

Add the following to the using directives at the beginning of the class file, SearchPreTrimmer.cs:

    using System.Security.Principal;
    using Microsoft.IdentityModel.Claims;
    using Microsoft.Office.Server.Search.Administration;
    using Microsoft.Office.Server.Search.Query;

We then define the class as implementing the ISecurityTrimmerPre interface in the class declaration:

public class XmlContentSourcePreTrimmer : ISecurityTrimmerPre

We have to define a few constants at the beginning of the class. These variables may be altered by the static properties given when the trimmer is registered with SharePoint.

    private string _claimType = "https://surface.microsoft.com/security/acl";
    private string _claimIssuer = "customtrimmer";
    private string _claimValueType = ClaimValueTypes.String;
    private string _lookupFilePath = "datafile.txt";

The initialization method of the trimmer may modify a few "constant variables", primarily claim type and issuer along with the file path to the input data of this trimmer's group membership data:

    /// <summary>
    /// Initialize the pre-trimmer.
    /// </summary>
    /// <param name="staticProperties">Static properties configured for the trimmer.</param>
    /// <param name="searchApplication">Search Service Application object</param>
    public void Initialize(NameValueCollection staticProperties, SearchServiceApplication searchApplication)
    {
        if (staticProperties.Get("claimtype") != null)
        {
            _claimType = staticProperties.Get("claimtype");
        }

        if (staticProperties.Get("claimissuer") != null)
        {
            _claimIssuer = staticProperties.Get("claimissuer");
        }

        if (staticProperties.Get("datafile") != null)
        {
            _lookupFilePath = staticProperties.Get("datafile");
        }

        RefreshDataFile();
    }    

The AddAccess method of the trimmer is responsible for returning claims to be added to the query tree. We will refresh the group membership data if needed and figure out the user id for key lookup into the group membership structure from the text file. 

    /// <summary> 
    /// Add custom claims to the query tree 
    /// </summary>
    /// <param name="sessionProperties">Session properties collection</param>
    /// <param name="userIdentity">query user identity</param>
    /// <returns>An enumerable of tuples with claims</returns>
    public IEnumerable<Tuple<Claim, bool>> AddAccess(IDictionary<string, object> sessionProperties, IIdentity userIdentity)
    {

        if (null == userIdentity)
        {
            throw new NullReferenceException("Error: AxdAccess method is called with an invalid user identity parameter");
        }

        RefreshDataFile();
        var claims = new LinkedList<Tuple<Claim, bool>>();
        var membership = GetMembership(GetUserId(userIdentity));
        if (membership != null)
        {
            foreach (var member in membership)
            {
                claims.AddLast(new Tuple<Claim, bool>(new Claim(_claimType, member, _claimValueType, _claimIssuer, _claimIssuer), false));
            }
        }

        return claims;
    }

We need a class to act as a simple wrapper of a Dictionary<string, string>. It should essentially serve as a key-value lookup from a user-ID to its group membership data. Each user's group membership has the form group1;group2;group3, where ";" is used to separate between each group membership entry. This class is simply called Lookup.

    private string GetUserId(IIdentity userIdentity)
    {
        // Run through all the claims of the claims identity, look for the
        // user logon name claim and primary SID to get the current user:
        //   domain\username
        ...
        ...

        return strUser;
    }

    private string[] GetMembership(string key)
    {
        lock (_lock)
        {
            var value = _lookup.Get(key);
            if (!string.IsNullOrEmpty(value))
            {
                return value.Split(new[] { ';' }, StringSplitOptions.RemoveEmptyEntries);
            }

            return null;
        }
    }

    private void RefreshDataFile()
    {
        if ((DateTime.Now - _lookupFileStamp).Seconds > 30)
        {
            lock (_lock)
            {
                _lookupFileStamp = DateTime.Now;
                if (File.Exists(_lookupFilePath))
                {
                    _lookup = Lookup.Load(_lookupFilePath);
                }
            }
        }
    }

Performance Considerations 

Consider the following tips to improve the overall performance with this trimmer as a starting point:

• Use multiple Lookup classes in a hash-table on a given key.
• Use a compressible stream and binary serialize the Lookup data.
• Use IPC (NetPipe) to talk to a local service that holds the more efficient key-value Lookups.

Deploying Trimmer

After you have built the custom security trimmer project, you must deploy it to the global assembly cache on any server in the Query role.

1. On the Start menu, choose All Programs, choose Microsoft Visual Studio 2010, and then choose Visual Studio Tools and open a Visual Studio command prompt.
2. To install the SearchPreTrimmer.dll, type the following the command prompt
   
   gacutil /i <ExtractedFolderPath>\PreTrimmer\bin\Debug\SearchPreTrimmer.dll
3. As the last step of deploying the trimmer, we need to learn about the token of the DLL. Type the following the command prompt
   
   gacutil /l SearchPreTrimmer
   Write down the token listed for the newly added DLL.

Registering Trimmer

1. Open the SharePoint Management Shell.
2. At the command prompt, type the following command:
   
   New-SPEnterpriseSearchSecurityTrimmer -SearchApplication "Search Service Application"
   -typeName "CstSearchPreTrimmer.SearchPreTrimmer, CstSearchPreTrimmer,
   Version=1.0.0.0, Culture=neutral, PublicKeyToken=token"
   
   where token is the text copied from the gacutil /l command above. Example: New-SPEnterpriseSearchSecurityTrimmer -SearchApplication "Search Service Application" -typeName "CstSearchPreTrimmer.SearchPreTrimmer, SearchPreTrimmer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4ba2b4aceeb50e6d" -Id 2
3. Restart the Search Service by typing
   
   net restart sphostcontrollerservice

Testing the Trimmer

Now, you can issue queries and you can see the beauty of the pre-trimmer logic in action for every query evaluated. Try modifying the datafile.txt for different group membership per user (keep in mind that contents of the data file are only loaded every 30 seconds). The 30 second refresh interval is a defined constant in the code. Enjoy!

Acknowledgements

Author: Sveinar Rasmussen (sveinar).

https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-55-87-Trimming/8357.PreTrimmer.zip

This blog entry describes how to take an existing custom XML connector to the Search service application, modify the connector to submit security ACLs as claims, install and deploy for SharePoint 2013 and test it. Using this blog post, you can index external sources with its security model within SharePoint itself. Keep reading and we will show you how.

Why Use Claims

Claims have the potential to simplify authentication logic for external contents in SharePoint 2013. Claims-based identity enables applications to know a few facts about the user's permission to view content. Thus, we can render legacy or different security models into custom claims in SharePoint 2013.

Modifying the XML Connector to send ACL information as claims should be helpful to demonstrate how to "light up" external content in search results, i.e. be able to search securely in any content.

Requirements 

• SharePoint 2013 Server
• Visual Studio 2012

The Starting Point: XML Connector

With this XML Connector as a starting point, we need to modify the connector code as it does not send security claims with its document submissions. 

The next two sub-sections are "greatly copied" from Anders Fagerhaug's blog post. A huge thank-you and many kudos goes out to him for producing a great starting point for a wonderful custom connector!

Install Custom Connector (Thanks Anders!)

Create Crawled Property for the Custom XML Connector (Thanks Anders!)

When the custom XML connector crawls content, the crawled properties discovered during crawl will have to be added to a crawled property category. You need to create this category. Note: The user that performs this operation has to be an administrator for the Search service application.

1. On the Start menu, choose All Programs, then choose Microsoft SharePoint 2013 Products and open a SharePoint 2013 Management Shell as an administrator.
2. To create a new crawled property category, at the command prompt type the following commands and run them, where: <ConnectorName> is the name you want to give the custom XML connector, for example Custom XML Connector:
   
   $searchapp = Get-SPEnterpriseSearchServiceApplication -Identity "Search Service Application"
   New-SPEnterpriseSearchMetadataCategory -Name "<ConnectorName>" -Propset "BCC9619B-BFBD-4BD6-8E51-466F9241A27A" -searchApplication $searchapp
   
   The Propset GUID, BCC9619B-BFBD-4BD6-8E51-466F9241A27A, is hardcoded in the file XmlDocumentNamingContainer.cs and should not be changed.
3. To specify that if there are unknown properties in the newly created crawled property category, these should be discovered during crawl, at the command prompt, type and run the following:
   

   $c = Get-SPEnterpriseSearchMetadataCategory -SearchApplication $searchapp -Identity "<ConnectorName>"
   $c.DiscoverNewProperties = $true
   $c.Update()
   
   where <ConnectorName> is the name you want to give the custom XML connector, for example Custom XML Connector.

Create Content Source for the XML Contents (Thanks Anders!)

To specify what, when and how the XML content should be crawled, you have to create a new content source for your XML content. Note: The user that performs this operation has to be an administrator for the Search service application.

1. On the home page of the SharePoint Central Administration website, in the Application Management section, choose Manage service applications
2. On the Manage Service Applications page, choose Search service application.
3. On the Search Service Administration Page, in the Crawling section, choose Content Sources.
4. On the Manage Content Sources page, choose New Content Source.
5. On the Add Content Source page, in the Name section, in the Name box, type a name for the new content source, for example XML Connector.
6. In the Content Source Type section, select Custom repository.
7. In the Type of Repository section, select xmldoc.
8. In the Start Address section, in the Type start addresses below (one per line) box, type the address from where the crawler should being crawling the XML content. The start address syntax is different depending on where the XML content is located.
   
   XML content is located on a local drive, use the following syntax:
   xmldoc://localhost/<XMLcontentfolder>/#x=doc:id;;urielm=url;;titleelm=title#
   
   XML content is located on a network drive, use the following syntax: 
   xmldoc://<SharedNetworkPath>/#x=doc:id;;urielm=url;;titleelm=title#
   
   XML content from the supplied example of this blog entry:
   xmldoc://localhost/C$/CustomSecurityConnector/#x=Product:ID;;titleelm=Title;;urlelm=Url#
   
   where given that you extracted the zip archive of this blog post to C:\CustomSecurityConnector.
9. Verify that your newly created content source is shown on the Search Service Application page.

The CustomSecurityConnector folder given with the ZIP archive contains Product.xml, which is a sample of a small product catalog.

Create a Crawl Rule for Content Source

It is useful to create a crawl rule if we want to do post-Security trimming for these documents.

1. Go to SharePoint Central Admin, choose Search Administration.
2. Under the Crawling section, choose Crawl Rules and then New Crawl Rule
3. In the Path field, type in xmldoc://* which should match up the CrawlUrl of the documents we will crawl in our example Product.xml file. Even if the Url in our data states urls along the lines of https://wfe/site/catalog, remember that these are the display urls. The SharePoint gatherer/crawler needs the access URL given in the content source setting.
   

   <!--                                                          -->
   <!-- Product                                                  -->
   <!--                                                          -->
   <Product>
   <ID>1</ID>
   <Url>https://wfe/site/catalog/item1</Url>
   ...
   </Product>

4. Select "Include all items in this path" and then create the rule by selecting OK

Crawl

Finally, start a full crawl of the newly created content source. Then select "View Crawl Logs" when the content source status goes back to the Idle status again. You should see 11 items successfully crawled.

Modifying the Connector to Send Custom Claims for Security

The Model.xml 

First, we need to change the Model.xml of the connector. To enable sending claims in the connector, we need to submit a binary security descriptor, a boolean to say that we will be providing our own type of security and finally an optional string field (docaclmeta).

Essentially, we need to notify the connector framework of our security field type descriptors plus set a few properties to enable this in the model.

Let's start with the TypeDescriptors first. For every item that we wish to enforce custom security on, we have to set the type descriptors for the following fields:

• UsesPluggableAuth as a boolean field type (if the value of this field is true = custom security claims instead of the Windows Security descriptors next)
• SecurityDescriptor as a byte array for the actual encoded claims data
• docaclmeta as an optional string field, which will only be displayed in the search results if populated. This field is not queryable in the index.

In the model file itself, the added lines for TypeDescriptors are encapsulated by the XML comments for Claims Security, part 1/2, like this: 

    <Parameter Name="Return" Direction="Return">
      <TypeDescriptor Name="Return" TypeName=... >
        <TypeDescriptors>
          <TypeDescriptor Name="Documents" TypeName=...>
            <TypeDescriptors>
              <TypeDescriptor Name="Item" TypeName=...>
                <TypeDescriptors>
                  ...
                  ...

                  <!-- Claims Security Start, part 1/2 -->
                  <TypeDescriptor Name="UsesPluggableAuth" TypeName="System.Boolean" />
                  <TypeDescriptor Name="SecurityDescriptor" TypeName="System.Byte[]" IsCollection="true">
                    <TypeDescriptors>
                      <TypeDescriptor Name="Item" TypeName="System.Byte" />
                    </TypeDescriptors>
                  </TypeDescriptor>
                  <TypeDescriptor Name="docaclmeta" TypeName="System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
                  <!-- Claims Security End  , part 1/2 -->

                  ...
                  ...

We are almost done with the model file. The only thing we have left is to supply the field names for the UsesPluggableAuthentication, WindowsSecurityDescriptorField and the DocaclmetaField, like this:

  <MethodInstances>
    <Association Name="GetAllDocuments_Instance" Type="AssociationNavigator" ReturnParameterName="Return" ReturnTypeDescriptorPath="Return.Documents">
      <Properties>
        ...
        ...

        <!-- Claims Security Start, part 2/2 -->
        <Property Name="UsesPluggableAuthentication" Type="System.String">UsesPluggableAuth</Property>
        <Property Name="WindowsSecurityDescriptorField" Type="System.String">SecurityDescriptor</Property>
        <Property Name="DocaclmetaField" Type="System.String">docaclmeta</Property>
        <!-- Claims Security End  , part 2/2 -->
        
        ...
        ...

The Entities.cs

We need to modify the corresponding C# code for the objects (i.e. documents) that the connector will submit with custom security ACLs. We have to adjust the Document class with the same fields as specified in the Model.xml:

• SecurityDescriptor
• UsesPluggableAuth
• docaclmeta

Thus, we added these three properties in the Entities.cs file as shown next:

public class Document
{
    private DateTime lastModifiedTime = DateTime.Now;
    public string Title { get; set; }
    public string DocumentID { get; set; }
    public string Url { get; set; }
    public DateTime LastModifiedTime { get { return this.lastModifiedTime; } set { this.lastModifiedTime = value; } }
    public DocumentProperty[] DocumentProperties { get; set; }
    // Security Begin
    public Byte[] SecurityDescriptor { get; set; }
    public Boolean UsesPluggableAuth { get; set; }
    public string docaclmeta { get; set; }
    // Security End
}

The XmlFileLoader.cs

Finally, we need to modify the connector code to get the input data for the security data, translate this into a corresponding byte array of claims and set the proper field values of the Document class.

Key points to note:

• The UsesPluggableAuth should only be set to true if we indeed will be supplying claim ACLs with this document.
• Claims are encoded as a binary byte stream. The data type of this example is always of type string but this is no requirement of the SharePoint backend.
• The encoding is done according to the protocol documentation where:
  - The first byte signals an allow or deny claim
  - The second byte is always 1 to indicate that this is a non-NT security ACL (i.e. it is a claim ACL type)
  - The next four bytes is the size of the following claim value array.
  - The claim value string follows as a Unicode byte array.
  - The next four bytes following the claim value array, gives the length of the claim type
  - The claim type string follows as a Unicode byte array.
  - The next four bytes following the claim type array, gives the length of the claim data type
  - The claim data type string follows as a Unicode byte array
  - The next four bytes following the claim data type array, gives the length of the claim original issuer
  - The claim issuer string finally follows as a Unicode byte array

The Input XML

We modified the input XML from the original connector, adding the claimtype, claimvalue, claimissuer and claimaclmeta field to the input:

<!--                                                          -->
<!-- Product                                                  -->
<!--                                                          -->
<Product>
<ID>1</ID>
<Url>https://wfe/site/catalog/item1</Url>
<Title>Adventure Works Laptop15.4W M1548 White</Title>
<Item_x0020_Number>1010101</Item_x0020_Number>
<Group_x0020_Number>10101</Group_x0020_Number>
<ItemCategoryNumber>101</ItemCategoryNumber><ItemCategoryText>Laptops</ItemCategoryText>
<About>Laptop with ... </About>
<UnitPrice>$758,00</UnitPrice>
<Brand>Adventure Works</Brand>
<Color>White</Color>
<Weight>3.2</Weight>
<ScreenSize>15.4</ScreenSize>
<Memory>1000</Memory>
<HardDrive>160</HardDrive>
<Campaign>0</Campaign>
<OnSale>1</OnSale>
<Discount>-0.2</Discount>
<Language_x0020_Tag>en-US</Language_x0020_Tag>
<!-- Security Begin -->
<claimtype>https://surface.microsoft.com/security/acl</claimtype>
<claimvalue>user1</claimvalue>
<claimissuer>customtrimmer</claimissuer>
<claimaclmeta>access</claimaclmeta>
<!-- Security End   -->
</Product>

With this sample input in XML, we have to modify the connector to pick up these extra XML tags.

We will create a GetXml method for this. For instance, we could illustrate one GetXml method where

• the first parameter is the tag name in the XML (e.g. "claimtype")
• the second parameter is the default return value for the GetXml method if the tag does not exist and finally,
• the third parameter is the XML element.

    var claimType = GetXml(documentAclClaimTypeElmName, "https://demo.sharepoint.com/acl", elm);
    var claimValue = GetXml(documentAclClaimValueElmName, "user1", elm);
    var claimIssuer = GetXml(documentAclClaimIssuerElmName, "windows", elm);
    var docAclMeta = GetXml(documentAclMetaElmName, null, elm);

With these variables properly filled out from the XML data, we need a method to transform these variables into a claims byte array. We will call this method GetSecurityAcl:

    private static byte[] GetSecurityAcl(
        string claimtype, 
        string claimvalue, 
        string claimissuer)
    {
        Byte[] spAcl = null;
        if (!string.IsNullOrEmpty(claimtype) && 
            !string.IsNullOrEmpty(claimvalue) && 
            !string.IsNullOrEmpty(claimissuer))
        {
            using (var aclStream = new MemoryStream())
            {
                var dest = new BinaryWriter(aclStream);
                AddClaimAcl(dest, false, claimtype, claimvalue, claimissuer);
                dest.Flush();
                spAcl = aclStream.ToArray();
            }
        }

        return spAcl;
    }

We need a method AddClaimAcl to add an encoded claim to a given byte stream:

    private static void AddClaimAcl(
        BinaryWriter dest,
        bool isDeny,
        string claimtype,
        string claimvalue,
        string claimissuer)
    {
        const string datatype = @"https://www.w3.org/2001/XMLSchema#string";

        if (string.IsNullOrEmpty(claimvalue))
        {
            return;
        }

        dest.Write(isDeny ? (byte)1 : (byte)0); // Allow = 0, Deny = 1
        dest.Write((byte)1); // Indicate that this is a non-NT claim type

        //
        // Claim Value
        //
        dest.Write((Int32)claimvalue.Length);
        dest.Write(Encoding.Unicode.GetBytes(claimvalue));

        //
        // Claim Type
        //
        dest.Write((Int32)claimtype.Length);
        dest.Write(Encoding.Unicode.GetBytes(claimtype));

        //
        // Claim Data Value Type

        //
        dest.Write((Int32)datatype.Length);
        dest.Write(Encoding.Unicode.GetBytes(datatype));

        //
        // Claim Original Issuer
        //
        dest.Write((Int32)claimissuer.Length);
        dest.Write(Encoding.Unicode.GetBytes(claimissuer));
    }

Now we have all our variables filled out. Next, we will set the properties of the Document class using these variables:

    var security = GetSecurityAcl(claimType, claimValue, claimIssuer);
    var doc = new Document
    {
        DocumentID = id,
        LastModifiedTime = fileModifiedTime,
        UsesPluggableAuth = security != null,
        SecurityDescriptor = security,
        docaclmeta = docAclMeta
    };

    docs.Add(doc);

That is really it. The connector will read the XML security information, encode the claims and supply the optional docaclmeta field before sending this to the SharePoint 2013 indexing backend.

The next blog post will outline how to write a custom pre-security trimmer to unlock these documents for users who are entitled to view it.

Acknowledgements

Author: Sveinar Rasmussen (sveinar)

A huge thank-you goes out to Anders Fagerhaug (andersfa) and Armen Kirakosyan (armenk) for the original Custom XML Connector blog entry.

https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-55-87-Trimming/6786.Connector.zip

Welcome to this tiny blog on custom security trimming for search in SharePoint 2013.

Typical scenarios to support could be to enable searching securely in 3rd-party content sources.

Back in SharePoint 2010 only post-trimming was offered for solving this scenario. Post-trimming refers to post-query evaluation where search results are pruned before they are returned to the user. With the new and shiny SharePoint 2013, we have now two types of security trimmers in our toolbox:

• Pre-Trimmer
• Post-Trimmer

The new pre-trimmer type is where the trimmer logic is invoked pre-query evaluation. The search server backend rewrites the query adding security information before the index lookup in the search index.

It is our hope to present you with explanations and examples showing you:

• How to take an existing connector, modify it to submit our own security ACLs as security claims directly, install it and deploy it
• How to write and deploy a custom security pre-trimmer
• How to write and deploy a custom security post-trimmer

I will write up a few blog posts on this in the coming days.
Stay tuned!