- How do we filter data so that users only see what they’re entitled to?
Since browser-compatible forms don’t support roles functionality, there’s no Out-Of-Box way to filter data based on membership. Fear not! It’s still possible, as outlined on the SharePoint Solutions Team Blog.
- What trust level should my InfoPath form run under?
This is a huge can of worms with several considerations. this MSDN article breaks down the capabilities of each trust level. When working with Full Trust forms, you’ll need to know how to publish Administrator-Approved templates to SharePoint Central Admin, as demonstrated on Jeff Schroeder’s blog.
- How do all of the pieces fit together? For a good overview of InfoPath Services architecture, check out this reference on MSDN. To get an even deeper understanding of Form Services, I strongly recommend Designing Forms for Microsoft Office InfoPath and Forms Services 2007 by Scott Roberts.
How can we securely filter access to the raw data contained in an InfoPath form?
As you may know, completed InfoPath forms are saved as unencrypted XML documents by default. Most often, these forms are submitted to a document library where many (or all) users have read access.
That’s a potential security hole, as users can open other users’ documents and access confidential data. This may not seem like a big problem, but it is:
"We can always implement security through custom views and conditional formatting. After all, the document library is set so that users can only view forms rendered in the browser, not through the client. That way, we’ll prevent users from seeing confidential data they shouldn’t."
That’s a natural assumption and we’d be copasetic if that was the whole story. True, by setting a document (or form) library to automatically open InfoPath files in the browser, users won’t be able to manipulate the document on their own hard drive.
However, it’s important to realize that users can always view the raw XML outside of InfoPath. They only need to right-click on an .XML file and select "Save As" in order to view the pure data, including hidden fields. Nothing is encrypted.
"That’s fine. We’ll lock down the document library using item-level permissions so users can only see their own work."
That should work, although it’s not alwayspractical. Setting up and maintaining item-level permissions can be confusing and error-prone. It’s also rigid.
What if users need to able to view portions of each others’ reports? For example, an organization may track service tickets through InfoPath. In that case, users should be able to see all ticket data, except for confidential fields such as passwords. What happens then?
"It’s not InfoPath’s responsibility to protect the data. We should secure our form using Information Rights Management."
I agree that would be the best case scenario, but IRM is not supported in browser-based forms.
"Maybe we can digitally sign the forms?"
We sure can (at least in Internet Explorer), but digital signatures in InfoPath are used for verification, not encryption. They’re great for authentication, not protecting the underlying data.
"Ok. Let’s just write our own encryption code."
That’s certainly an option, but it’s overkill. Advanced developers may be able to write encryption code and decryption code in the Form_Submit and Form_Load event handlers, but that introduces a great deal of complexity and, in turn, new challenges. For starters, how do we distribute keys?"Well, what do you suggest?"
I’m glad you asked. I suggest we write our own HttpModule to filter XML files from a given document library.
- An HttpModule listens for all requests within a given path.
- A custom method is set to process the BeginRequest event.
- Whenever an XML file is requested in that path through IIS, our custom logic filters the request.
- The filter either blocks certain users / groups from accessing the XML file altogether or filters out confidential sections of the form.
- Filtering can consist of an XSL Transform to omit protected sections or to block all content.
