

We decided to implement a custom claim provider that would query the CRM system at login for customer claims based on the user ID. On upload (based on the customer that was assigned to the document), we used the content organizer to route the document to the correct site, library and folder based on the organization and security rules that we had. Each library had a claim for the customer assigned to it so only users with that claim could view the documents in the library. We would use search for the UI so that the users had a single place to find and view the documents. Sounds simple, right?
It should’ve been.
Unfortunately, the implementation was anything but simple. From the beginning, we hit the core limits of SharePoint 2010, FAST and Claims. Now that we’ve made it to the end, I want to talk about the limits we ran into and steps you can take in your design to avoid them. Read More…
One of the first things I struggled with, though, was how to access the data through the SharePoint Client Object Model in the Host Web. Every code sample out there just works with data within the app, and doesn’t try to go back to the Host Web to get the data. Since there is a security barrier between the app and the Host Web, you can’t access data in the Host Web through the client context of the app. You must retrieve the site through a special method in the SharePoint API called AppContextSite.