Web Slice and Feed Authentication – Developer Guidelines

Hello, my name is Amy Adams and I’m a Lead Software Design Engineer in Test on Internet Explorer’s Web Service Integration team.  I wanted to take this opportunity to talk about the different mechanisms for providing a great and secure experience for Web Slices and feeds.  We first described Web Slices when we launched them in IE8 beta 1, and also talked about the improvements we made to Web Slices and RSS in IE8 beta 2 as well as the post Ritika recently made about Dynamic Web Slices.  

Now available in IE8 RC1 is HTTP authentication support for feeds and Web Slices.  And cookie/forms based authentication that is persisted‘just works’.  There are multiple ways for publishers to implement authenticated Web Slices and feeds.  The 4 options I’ll be discussing are:

1. Persistent login cookies (“remember me”) 
2. Web Slice specific auth cookie
3. Unique subscription URLs
4. HTTP Authentication

Each of these options has benefits and tradeoffs that can help you determine which solution (or combination of solutions) works best for your needs.  Ask yourself, is the content in the Web Slice PII that must be protected by cookie authentication, or is it content that can afford “less protection?”   Knowing the answer to this question will help you choose the best option (or combination of).

There are many other authentication schemes, but four these are the most prevalent on the web today.  Other authentication mechanisms are also in the process of becoming popular.  We are continuously looking at the developments in the authentication space to if it makes sense to support those for feeds and Web Slices.

Let’s get into detail…

1. Persistent login cookie (“remember me”)

Web Slices will get cookie support for free because the browser will send cookies, when present, along with HTTP requests for a particular URL. 

How it works:

Many sites already allow users to “remember me,” or persist login credentials that are stored in a cookie on the user’s machine.  The site usually sets a persistent cookie with a future expiration date of, for example, 2 weeks from the time of login.  During this time, the site will allow access without the user having to log in.  IE will send up user cookies with every URL request assuming the cookie exists.  Feed and Web Slice download requests are no exception to that.  Note that session cookies will NOT work for receiving updates to feeds and Web Slices.  This is because, due to Protected Mode work implemented in IE7, session cookies are not shared between cross integrity level processes (in this case msfeedsync.exe runs at medium and iexplore.exe runs at low). So, if a user logs out of the site, they will no longer be able to receive updates to the Web Slice.

Example

Consider the following scenario.  A banking site requires a user to log in to their site.  The user logs in and chooses to save their username and password by checking the ‘remember me’ box on the site (not to be confused with IE’s built in password auto complete feature).  The site creates a cookie on the user’s machine that will expire in 2 weeks.  Future updates to the Web Slice will just work until the cookie has expired.  When the cookie expires, the site shows a custom crafted login form that fits nicely into the 320x240 pixel preview window of the Web Slice.

Here’s an example of how a tailored 320x240 login form could look in this scenario when the cookie has expired or there is some other type of error logging into the site.  

If you don’t like the idea of creating a custom login form in the 320x240 window, then you can simply add a link (use target=_blank) to login at the site. 

Design considerations:

• Recommended for Dynamic Slices only - This method is only recommended for Dynamic Web Slices, not feeds or the other types of Web Slices.  The reason being that there is no friendly way to display a login form within a feed.  Form controls in normal RSS feeds and non-Dynamic Update Source Web Slices are disabled for security reasons.
• Users logging out will cause updates to stop working – As mentioned above, users might not realize that logging out of the web site also prohibits the Web Slice from updating in the background.  Also, “Remember me” is not traditionally checked by default, which means publishers need to communicate to users that the user should “check remember me” in order for the Web Slice to work the best.  You will need to provide a login mechanism within the preview window, like the one above.
• Server responses need to be understandable to the Windows RSS Platform – Depending on how you decide to implement the Web Slice to get updates, make sure when auth fails due to no cookie, the response returned is in a format that the Windows RSS Platform can understand (either a Web Slice or feed).  Returning an unrecognized response code or other type of error will cause an error to appear in the Web Slice UI. 
• Use SSL - It is strongly recommended that you configure the server to require SSL in this scenario.  This will add extra protection and avoid credentials being sent in the clear over the wire.
• Get Phishing and Certificate Validation for free - It should be noted that full certificate validation and SmartScreen support has been implemented for Dynamic Web Slice urls.  So, users will get an extra layer of protection against Phishing attacks and identity theft.  If a Phishing URL is detected, a block page is displayed in the 320x240 preview window.  And, the certificate assurance badge is displayed for SSL sites (examples shown below).

The Suggested Sites Web Slice that ships out of box with IE8 is a good example of certification validation experience:

2. Web Slice specific authentication cookie

This option is applicable only for Dynamic Web Slices or slices using an Alternative Update/Display Source or feedurl.  Given the pervasiveness of cross site request forgery vulnerabilities (CSRF), this may be a more secure option than relying on persistent cookies for Web Slice authentication.  With this option, the user doesn’t have to choose between Web Slice functionality and the security of “signing out of sites”.  Here, a Web Slice publisher will use a separate persistent cookie just for the Web Slice entry-content href or feedurl.  This cookie permits just the download of the Web Slice content (which usually is read-only). 

How it works

When the user subscribes to the Web Slice, the server sets a persistent cookie for the URL that contains updates to be synced.  By default, cookies are set for a particular domain.  To set a cookie for just the update url, depending on how your server is implemented, you can scope the cookie to a particular folder on the site OR to a particular sub domain.  Or, you can do server side plumbing to validate that the cookie (e.g. via unique name/value pairs or other extra data within the cookie) contains “login credentials” that are just-enough to identify the user to the server and provide access to only the data in the Web Slice.  In other words the cookie should only work on the particular Web Slice URL, but not anywhere else on the domain. 

Design considerations:

• Extra cookies means extra work - Publishers will have to deal with a second kind of authentication cookie, validating it, expiring it, etc. which is more work.  
• Should get user’s consent - It is recommended you put specific notice on the subscribe page to inform the user that a cookie is being set on their machine to sync updates.
• It should also be mentioned that the tradeoffs discussed in section 1 still apply here too.

Example:

Let’s say you’re the publisher of a social music site and users have to login to see the content.  When they subscribe to a Web Slice to keep track of the top 20 songs, instead of using the site domain cookie, you generate a persistent read-only cookie scoped for a subfolder on the domain which contains just the Web Slice or feed of the top 20 songs.  If the cookie expires or the user deletes it, then the Web Slice preview could display a custom form (if Dynamic) or a link to go login somewhere.  Or you could just re-generate the cookie when they sync updates (depending on the scenario).  Here’s how the code could look for this:

<div class="hslice" id="top20">
        <h2 class="entry-title">Top 20 Downloaded Songs</h2>
        <a rel="feedurl" href="../SyncUpdatesFolder/default.aspx#top20" style="display:none;">
             Alternate Update Source - /SyncUpdatesFolder/default.aspx#top20</a>  
</div>

Here the cookie would only apply to content under the SyncUpdatesFolder (using the Path cookie attribute while setting the cookie).  Then, the code for default.aspx (in C#) could look like:

<%@ Page Language="C#" %>
<%
    if (Request.Cookies["username"] != null)
    {
          //cookie exists display content
          HttpCookie aCookie = Request.Cookies["username"];

          //write out Web Slice with updates
          Response.Write("<div class=\"hslice\" id=\"top20\"><h2 class=\"entry-title\">Top 20 Hits </h2><P class=\"entry-content\"> The cookie existed, here's the top 20 songs, and more…</p></div>");
    }

  else
  {
           //no cookie, write out error message with link to login
           Response.Write("<div class=\"hslice\" id=\"top20\"><h2 class=\"entry-title\">Top 20 Hits </h2><P class=\"entry-content\"> No cookie, You need to <a href=\"logon.aspx\" target=\"_blank\">click here</a> login.</p></div>");
   }
%>

Or, you could just have all your Web Slices exist on subfolders or domains on the site and avoid putting them on the main site, then you don’t have to worry about having an extra feedurl to sync updates from. 

3. Unique Web Slice URLs

A variation of #2 is the use of unique Web Slice URLs which would be unique to the user but could be used without cookies.  When used without cookies, this is a not secure method, but it might be sufficient depending on the information provided in the particular Web Slice. 

How it works:

Consider the following scenario: a Web Slice contains public information but is scoped to a particular user.  Think of a scenario where you want to track new albums created by certain artists.  Although public information, it is content tailored to a user’s query.  Instead of having the user authenticate, you can have code that runs on the server to dynamically generate the entry-content href or feedurl.  Note that generating this content using AJAX will not work, but instead it must be server side code to generate the unique URLs (see example below). 

Design considerations:

• More server side plumbing required – this method requires a unique URL for each Web Slice and could actually be more work on the server side.   
• Not a secure option when used without authentication - Unique URL approach shouldn’t be used for Web Slice that contain sensitive information (unless you have the capacity to generate unique cookies for these URLs and can do this over SSL)
• Must generate unique URLs using server side code – As mentioned above, you must generate the unique URLs using server side code.  Ajax will not work because the Windows RSS sync engine can only check for updates on the HTML/xml returned from the server.  It can’t simulate what a user would do to dynamically change the page after it’s loaded.

Alternative Update Source example:

In the code below, the asp server side code in <% … %> is used to generate the unique URL for the user.

<div class="hslice" id="<%=id%>">
    <h2 class="entry-title">Unique URL Slice</h2>
    <a rel="entry-content" href="../display.aspx?userid=<%=guid%>" style='display:none;'>Alternate Display source for <%=guid%></a>
</div>

4) HTTP Authenticated Web Slices and Feeds

The IE8 Windows RSS Platform now has support for HTTPS BASIC and HTTP/S DIGEST authentication.  This option is the only supported option for setting credentials for a feed or Web Slice via our new RSS authentication APIs.  

This table describes the supported HTTP authentication schemes in IE8:

Authentication	HTTP	HTTPS
BASIC	Not supported	ok
DIGEST	ok	ok

Aside from cookie/forms based authentication, these are the most prevalent HTTP authentication schemes on the internet today.  Other authentication schemes (e.g. Kerberos and NTLM) should typically ‘just work’ as the operating system will already handle these schemes outside the Windows RSS platform and users will already be authenticated to these servers (e.g. by joining a computer to a domain over NTLM) and will only access those Web Slices or feeds when within that realm.  Also, other HTTP authentication schemes that require prompting outside the context of the RSS platform (e.g. Certificate picker for client auth certificates) are specifically not supported because the Windows RSS Platform cannot simulate user actions in these scenarios.  And, even more importantly, this is a poor experience for users as they will be shown a dialog out of context and may not know what they are being prompted for.

How it works

When any supported HTTP authentication method is used, the user experience will be as follows.  If users are subscribing to an authenticated Web Slice and/or feed and has not already been authenticated to the server, then they will get prompted for credentials during subscription.  However in many cases, they navigate to the authenticated server first, log in, and then subscribe to a Web Slice or feed.  Since the users are already authenticated during time of subscribe, the initial download just works.  On the next feed and Web Slice sync, users will see an error indicating that a username and password is required.  Clicking the error, will launch the feed and/or Web Slice properties dialog where they can enter these credentials.  After this, future syncs to the data will work as long as the server accepts those credentials.   

Here’s a screenshot of the Web Slice error to enter credentials. 

Clicking the error button will bring up the feed property dialog to enter credentials:

Design Considerations:

• Not recommended for Dynamic Web Slices - This option is not recommended for Dynamic Web Slices because the user experience is not ideal and because we are subscribed to a different url than what is shown to the user in the Preview window..  What happens is after download of the Web Slice, the first time the user clicks to view the content, they will be prompted for credentials with the Windows Credential Manager dialog.  This may be a confusing experience since the dialog will show out of context and the user may not realize who/what is prompting for credentials.  Also, it can be deceiving since the user may not realize they are entering credentials for a different url than what is shown to them in the Web Slice.
• Not supported for enclosures - Feed enclosures cannot be authenticated at this time
• Server response codes -  It is required that the server challenge the requests to the Web Slice or feed with a regular HTTP auth challenge (HTTP 401 Auth required response).  This will produce the experience mentioned above and the user will be prompted to enter credentials
• Why BASIC Auth only via SSL?  We must not send out user credentials in the clear in a background process, in this case the Windows RSS sync engine process.  The user is “somewhat” in control when s/he chooses for their credentials to be sent in the clear (e.g. by logging into a non SSL site).  But for subscribed content s/he won’t know when the credentials will be sent.  Imagine the scenario of going to free Internet café and having your credentials being sent in the clear over a non-secure wireless connection when IE downloads your feeds in the background. 
• Using an alternate feedurl to subscribe to for authenticated Web Slice: Similar to option 2, instead of requiring that the Web Slice is only reachable via HTTPS, it’s possible to make the Web Slice reachable via http and https.  Then have the Web Slice include the <a rel="feedurl" href="https://..."> construct to point to an alternate URL to subscribe to for the Web Slice.  In this case the “feedurl” should point to the same Web Slice but instead of http it should be https so that the user will be subscribed to the SSL version.  This approach has the additional potential benefit of allowing the regular http Web Slice to use cookie authentication, but the https version to use HTTP Authentication. This means that HTTP Authentication is only used when the user is actually subscribing to a Web Slice and not when just browsing to pages with Web Slices. 

There are other options for authentication, but these are the main four we recommend and support.  In summary, the following table describes the authentication support in IE8 for feeds and Web Slices.

Type/Option	1) Persistent cookies	2) Web Slice specific cookie	3) Unique Urls	4) HTTP auth
Regular Web Slices (The slice does not use an Alternate Display/Update source.)	Ok1	Ok1	Ok	Ok
Dynamic Web Slice (The slice uses an Alternate Display Source.)	Ok	Ok	Ok	Not recommended2
Alternate Update source (The slice uses a feedurl to get updates.)	Not recommended3	Not recommended3	Ok	Ok
RSS feeds	Ok	Ok	Ok	Ok

¹ This is ok, but you will have to create a web slice or single item feed response containing login information that will be shown when the cookie is not present.  This may not be possible depending on how you’ve implemented the Web Slice or feed.

²Not recommended because the user will get a confusing auth prompt when opening the web slice after subscription.  And, the user may not be aware of what they are entering credentials for.

³ Not recommended because you’re syncing updates from a different place than what is shown to the user.  To make this work, you’d have to somehow figure out that the feedurl sync failed and generate a new slice on the main page to display to the user that auth is required.  It is possible but extra work.

Thank you and I hope you have fun developing secure Web Slices!

Amy Adams (a.k.a. Amy P)
Lead Software Design Engineer in Test
Web Service Integration Team

Update 3/19/09: Updated code samples to add missing quotations and for better accessibility. 
Update 1/14/10: Updating author's name.