InfoPath Demo: Password-protect InfoPath forms in SharePoint

by S.Y.M. Wong-A-Ton

In this InfoPath demo you'll see an example of using encryption and a password to protect the data that is stored in fields on an InfoPath browser form in SharePoint.


In this InfoPath demo, you saw…

  • How to use a password to protect fields on an InfoPath browser form in SharePoint.
  • How an InfoPath form that is created and protected by a user cannot be unprotected by another user even if that user knows the password with which the form was protected. The data can only be decrypted and read by the person who protected the InfoPath form.
  • How you can download the InfoPath form from the SharePoint Form Library, store it locally on disk, open it in Notepad, and still not be able to read the sensitive data stored within the form.
  • How all of the data from the fields on the InfoPath form that require protection is stored in an encrypted format in a hidden field on the InfoPath form.

The InfoPath demo shown above is based on an ASP Alliance article (Password-Protecting Sensitive InfoPath Form Fields) I wrote way back in 2006 for InfoPath 2003.

I modified the code slightly to work with InfoPath 2007, and came up with an entirely different solution to encrypt and decrypt data in an InfoPath browser form in SharePoint.

I was inspired to come up with this solution for one of my ASP Alliance readers who was struggling to find a suitable way to convert the previously mentioned article and apply it to his scenario.

 Subscribe (RSS | Email)

Related Posts

See more InfoPath 2007 videos »

  1. 3 Responses to “InfoPath Demo: Password-protect InfoPath forms in SharePoint”

  2. StefanS
    Posted Sunday, 21 March 2010

    Luctor et Emergo ;-)

    Thanks for the solution.

    Since the encryption blows up the amount of characters of the protectedFields nodes, will it become a problem to store my 39 fields in the encypteddataField that is of the type string with a certain limit on number of characters. Is the base64 attachment field maybe more usefull here and easy to apply since we are already using System.Security.Cryptography ?

  3. S.Y.M. Wong-A-Ton
    Posted Monday, 22 March 2010

    Those are all valid questions, which to be honest I have not tried out. Worst case scenario, you’d have to split the protectedData field up into multiple fields to accommodate your 39 fields.

    I don’t know what the limitations are of controls in InfoPath, so you’d have to give it a try. If it does not work, let me know. And if you find something worth mentioning, let me know too.

  4. S.Y.M. Wong-A-Ton
    Posted Monday, 22 March 2010

    Come to think of it, you should not have issues with the InfoPath controls themselves, because the protectedData field is a hidden field (not shown on any View).

    I don’t know whether the “base64Binary” data type accommodates more characters than the “string” data type, but you should be able to find out. Since you’ll be writing to XML nodes through code, it should not matter what you use in the data source.

    Another thing that could fail when you use a large amount of text are the .NET methods to encrypt and decrypt. Again, if you hit any limitations, you may have to come up with a way to split the fields into multiple group nodes or be very selective as to which fields need protection and which do not.

    Let me know how you get on.

Comments to this post were closed 30 days after it was published.

Copyright: This article may not be used on web sites (whether personal or otherwise), copied, disseminated, altered, printed, published, broadcasted, or reproduced in any way without an expressed written consent of S.Y.M. Wong-A-Ton. Usage of techniques demonstrated in this article may be used within any Microsoft InfoPath project. This article is provided without any warranties. Copyright for this article is non-transferrable and remains with the author, S.Y.M. Wong-A-Ton.

Working with InfoPath