KB001556: P3P, Security Token Issues with IFrames and Cookies in IE

Platform for Privacy Preferences Project (P3P) is a protocol that allows websites to declare their intended use of information. The K2 software that you install with K2 blackpearl and K2 smartforms uses P3P policies on generated pages to enable the pages to work seamlessly without additional configuration.

For more information about P3P see the following topics:

• P3P (http://en.wikipedia.org/wiki/P3P)
• Platform for Privacy Preferences (P3P) Project (http://www.w3.org/P3P/)
• P3P Writer (http://www.p3pwriter.com/LRN_111.asp)

The following policies are used on the sites that generate pages that are used by K2 end-users:

• NON: No access to identified data is given.
• DSP: The privacy policy contains DISPUTES elements
• COR: Errors or wrongful actions arising in connection with the privacy policy will be remedied by the service.

What this means is that for browsers that support P3P, the declaration of these policies are passed via the HTML Headers mechanism when pages are loaded from a corresponding K2 site. When the browser sees these policies in effect it will allow the site to load its content. Otherwise it will return an error.

The K2 sites that include these policies by default are:

• K2 smartforms Designer
• K2 smartforms Runtime
• K2 View Flow

If you do not want these policies to be on your K2 sites you can modify or remove the P3P key from the web.config files corresponding to the sites. These are located at:

• K2 smartforms Designer: [install drive]:Program Files (x86)K2 blackpearlK2 smartforms DesignerWeb.config
• K2 smartforms Runtime: [install drive]:Program Files (x86)K2 blackpearlK2 smartforms RuntimeWeb.config
• K2 View Flow: [install drive]:Program Files (x86)K2 blackpearlWebServicesViewFlowWeb.config

 The key to remove for the first two sites is highlighted here:

  <system.webServer>

    <httpProtocol>

      <customHeaders>

        <remove name="Vary" />

        <remove name="X-Powered-By" />

        <remove name="X-UA-Compatible" />

        <add name="X-UA-Compatible" value="IE=10,IE=9,IE=8" />

        <add name="Vary" value="Accept-Encoding" />

        <add name="p3p" value='CP="NON DSP COR"'/>

      </customHeaders>

    </httpProtocol>

  </system.webServer>

From the view flow web.config remove the following key:

  <system.webServer>

    <httpProtocol>

      <customHeaders>

        <add name="p3p" value='CP="NON DSP COR"'/>

      </customHeaders>

    </httpProtocol>

If you remove or modify these keys, you may need to use the Trusted Sites feature in Internet Explorer for your sites to load K2 content.

Symptoms of Removing or Modifying the P3P policy

At times in K2 for SharePoint an IFrame pops up requesting Login Method. You select a login method and end up going through the login loop, always ending up back on the login page.

This has to do with IE’s treatment of First-party and Third-party pages.  Any page that has been IFramed or popped up is considered to be a third-party page.  The page that you loaded originally from the address bar is the first-party page.  IE manages policies between these two in a couple different ways – via Trusted Sites and via Privacy Policy.

Option 1 - Trusted Sites

Setting up all the necessary Trusted Sites is the recommended method of overcoming the login loop issue if you've removed the P3P policy. You need to make sure you have trusted all the sites that are participating in the solution – K2, SharePoint, MS Auth, K2 Auth. Once you do that, all will work seamlessly.

Note that using the *.domain.com approach covers both HTTP and HTTPs and is much easier to type and setup.

Here’s a list of trusted sites and how they fit into the overall K2 for SharePoint app experience. Your entries may be different, but you need to makes sure you have all the roles covered.

An example of the Trusted Sites configuration for the Denallix domain would look like the following. In this example, the K2 server is in the same Denallix domain as the SharePoint server, which are both covered by the wildcard *.denallix.com

Cookies are the reason having the correct sites in Trusted Sites resolves the login loop issue.

When moving from a SharePoint site to a K2 site, your identity is passed along and we check to see if you’ve already logged into the K2 site by looking for a cookie. If we don’t find that cookie, we route you through the login loop, sometimes with prompts, but most of the time automatically, and then we save your info in a cookie so we don’t do that loop again. Cookies are tied to the issuing domain and the ability for the browser to save the cookie is based on your individual browser settings as they relate to policy. Adding a site to Trusted Sites tells the browser that you will accept cookies from that domain for both first party and third party sites.

If you are being prompted to login multiple times to SharePoint or K2, you may want to modify your Internet Explorer settings to automatically login. Go to Internet Options, and then on the Security tab click Trusted Sites and click Custom Level. Scroll to the bottom of the settings page and select Automatic with current user name and password.

Option 2 - Privacy Policy

The Privacy Policy settings in IE give you complete control over what you will allow to happen with cookies.  You can determine to explicitly allow or block cookies from a domain all together via the Internet Options > Privacy > Sites options as shown below.

This shows that even though the site has been enabled via Trusted Sites, we will still have the same issue because cookies are not allowed to be saved. Likewise, if you don’t have the site in Trusted Sites and you explicitly add it via this dialog as Always Allow, the cookies will get saved and the app flow experience will work.

Option 2.1 - Advanced Privacy or Troubleshooting Cookies

You can get even more granular than this though and decide on a per-cookie basis whether you want to allow IE to save the cookie.  This is not practical in the real world as a solution as the end user will be prompted for every cookie.  However, it is a great troubleshooting tool for folks trying to figure out how all this works.

To see this in action, open up Internet Options > Privacy > Advanced and enable Prompt for Third-party Cookies.

Once you do that and navigate to the K2 app in SharePoint, you will start to see something like the image below. The authentication loop results in 5 cookies being written so you will see this 5 times on a standard page. Using this with Fiddler will help you to understand exactly when we try to save the cookie to disk as well as what the cookie looks like. You can also see when we are able to simply use an existing cookie by the fact that you are not prompted on refresh.

Additional Note: These settings don’t always work together as you would expect. A site in the Always Block list will always be blocked and never save a cookie. Likewise, sites in Trusted Sites and not in Blocked will automatically save your cookies even if you configured the prompt. The best approach is to use only one of these three settings at a time to ensure you get the testing results you are looking for.

For more information, see: Understanding Cookie Controls