다음을 통해 공유

InfoPath SP1 Security

  • 아티클

Note: This post doesn't go over the SP-1 deployment model. If you want to learn about that, read this post from the InfoPath Team blog.

InfoPath has a rather unique security model. It borrows a bit from IE, a bit of its own, and with SP1, it adds a little bit of .NET security to the mix.

IE Security: Internet Explorer security is based on the Zones concept. There are 5 zones (going from most restrictive to least restrictive) Restricted, Internet, Intranet, Trusted Sites, and the non-configurable Local Machine zone. If your webpage has script which tries to create an unsafe ActiveX control (like FileSystemObject), it will get an error on every zone except Local Machine, and Trusted Sites, where you will be prompted. Also, if your script tries to access a resource on another “domain” (a.k.a website), you will get access denied in the Internet Zone, prompted with that friendly “This page is accessing information that is not under its control. This poses a security risk. Do you want to continue?” dialog in the Intranet Zone, and your call will succeed on the Local Computer or a Trusted Site. If you had script in an InfoPath custom HTML task pane, it would naturally behave the same way.

InfoPath-specific Security:InfoPath can run script in a custom HTML task pane, but it also can run script as built-in business logic to respond to events like OnLoad of the form, or OnClick of a button. InfoPath has its own Object Model, and each property or method has it's own security level:

  • Level 0: Level 0 properties/methods can be called by anyone, anywhere. They are very innocuous methods that are considered safe no matter who calls them. (Ex. Application.FormatString)
  • Level 2: To understand level 2 methods, you need to understand that InfoPath forms can communicate with each other. I can say Application.XDocuments.Item(1) from my business logic and get access to another form that's currently running on the machine. Whether or not this call will succeed or not is based on whether the Form Template (xsn) file is located on the local machine or Trusted Sites, the Intranet Zone, or the Internet Zone.(InfoPath forms don't run if the Form Template (xsn) file is located in the Restricted Zone). In addition, any paramaters in a method call are checked to make sure they are not accessing information in another Domain. The vast majority of the InfoPath OM is level 2 (Ex. XDocuments.Open, XDocument.UI.Alert, etc)
  • Level 3: These methods/properties are considered unsafe no matter who is calling them. The only way to prove that you are trustworthy enough to call them is if your form template is Fully Trusted. This means that you must register the form call the ExternalApplication (or just Application in SP1) RegisterSolution method, or you can digitally sign the form (SP1 only). You can also use the RegForm tool in the InfoPath SDK to generate a .js or .msi file to register the form for you.

.NET Security: With InfoPath SP1, you have the option of writing business logic in managed code. I won't get into all of the details of Code Access Security, but let me say this. InfoPath Forms with managed code business logic, unlike regular .NET console applications, do not have FullTrust permissions on the local machine. It is granted the LocalIntranet Permission Set instead. This means you won't be able to willy-nilly create TextWriters and overwrite your friend's boot.ini file just by getting him to open an InfoPath form. It also means you won't be able to create TextWriters (and many other .NET Framework Objects) while you are developing your form. If you'd like to learn how to configure the InfoPath Form Templates group using the .NET Configuration 1.1 utilitiy, check out this page from Roger Jennings (Note: There's a security warning in there about how not to expose yourself to attack. READ IT! )

Putting it all together:

These are just a few interesting facts that “naturally“ (or not so naturally) fall out of the 3 security models

    • Granting your managed code business logic FullTrust Permissions will have no effect whatsoever on your script running in the custom task pane.
    • Running a form with managed code business logic from a IE Trusted Site will cause the business logic to fail with a security exception. Why? .NET Security grants IE Trusted Sites the Internet Permission Set by default. InfoPath forms with managed code business logic won't even open in the Internet Zone.
    • Granting Full Trust to managed code business logic does not entitle you to call InfoPath OM Level 3 methods.
    • Granting your InfoPath form Full Trust (by registering or signing it) does entitle your managed code business logic to the FullTrust permission set.
    • Communication between the taskpane and managed code business logic requires that your managed code has FullTrust permissions (because it needs to call into unmanaged code). If your form needs to communicate with the taskpane, try to stick with script for your business logic, if you can.
    • Email-deployed forms will not be able to use managed code business logic.
    • Do not taunt Happy Fun Ball™

Comments