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.

Comments

• Anonymous
  March 11, 2009
  PingBack from http://www.clickandsolve.com/?p=21473

• Anonymous
  March 11, 2009
  Web slices seem interesting -- but I just don't quite get the "toolbar in the browser" implementation. In Vista, slices should be items in the sidebar.  In Vista and XP, the favorites toolbar should be addable to the taskbar so that you can have access to them from whatever app you're in. I suppose that since you're the IE team you guys spend most of your time in the browser, but some of us spend our time in other apps.  Exposing web slices via sidebar or taskbar would be a huge benefit to us. (Of course, as soon as one thinks of sidebar, one is reminded that sidebar gadgets already provide a lot of the purpose of web slices, e.g. the token "weather" web slice one always sees.  And of course, sidebar gadgets are just a decade-later version of Active Desktop :))

• Anonymous
  March 11, 2009
  This is offtopic but i was wondering if it's possible for IE8 final build to support animated png files, see this for me info: http://en.wikipedia.org/wiki/APNG

• Anonymous
  March 12, 2009
  What would be immensely useful: restore previously opened tabs. While Firefox's "Show my windows and tabs from last time" option took a while to get used to it is ultimately one of the most helpful features and I doubt it would take too much effort to implement in to IE. IE restores tabs when IE crashes, so why not after simply closing it out? ...or is this already implemented and have I missed this feature?

• Anonymous
  March 12, 2009
  @John A Bilicki If you open a new tab in IE8, there is an open to "Reopen Last Browsing Session".  I think this does what you were referring.

• Anonymous
  March 12, 2009
  The comment has been removed

• Anonymous
  March 12, 2009
  Can you guys set up some sort of review before posting option? Once again, please, never ever release BAD code samples. Ever! What is all this garbage? 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>"); Try: 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>");

• Anonymous
  March 12, 2009
  Sorry if I am going a little off topic here, but I would like to ask the IE Team for a feature: to autohide the status bar in full screen mode, as well as other bars do. Thank you.

• Anonymous
  March 12, 2009
  I am so glad that web slices are going to be part of IE8! THANK YOU MICROSOFT!!! Hooray!

• Anonymous
  March 12, 2009
  Thank you for submitting this cool story - Trackback from DotNetShoutout

• Anonymous
  March 13, 2009
  @PatriotB:  This is good feedback.  Yes a sidebar extension for Web Slices is a great idea!  - Amy P [MSFT]

• Anonymous
  March 13, 2009
  @PatriotB: http://blogs.msdn.com/justsean/archive/2008/03/19/webslice-viewer-gadget-alpha.aspx

• Anonymous
  March 13, 2009
  The comment has been removed

• Anonymous
  March 13, 2009
  The comment has been removed

• Anonymous
  March 13, 2009
  "this is an example of violating the user's trust." What exactly are you talking about??

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 14, 2009
  IE8 Gallery provides many Web Slice add-on that you may want to try. In this post, I will share about

• Anonymous
  March 15, 2009
  The "hslice" examples in the last post about web slices were updated to reduce their negative accessibility impact, for example by including link text for links. Would it be possible to fix this example in the same way?

• Anonymous
  March 15, 2009
  so do I understand correctly that IE will fail to authenticate the way normal web sites work? on every site I visit, the first attempt to access private content redirects to a login page, the user logs in, then redirects back to the content they planned to view. This scenario fails on every Web Slice I've tried.

• Anonymous
  March 16, 2009
  @authentication fail:  Thanks for reporting the issue.  Can you provide a link to a repro so I can confirm what's happening here?  I'm guessing that you didn't persist your logon informmation which would cause a redirect to a logon page when the RSS Platform attempts to download and subscribe to content.  Since the logon page doesn't contain a feed or Web Slice, it doesn't really know what to do with it and will display an error.  However, that's just my guess, I'll need a repro to confirm.  Thanks, Amy P [MSFT]

• Anonymous
  March 16, 2009
  @Benjamin Hawkes-Lewis:  Yes, thanks for pointing this out.  I'm working on it. Amy P [MSFT]

• Anonymous
  March 17, 2009
  So you don't support basic auth over unencrypted http, but you do support secret URLs? That seems inconsistent. I would recommend either ditching secret URLs or allowing the abomination that is basic auth.

• Anonymous
  March 17, 2009
  @Geoff Greer:  Can you elaborate on what you mean by 'secret URLs'?  Are you referring to unique urls per user?  This is not considered a secure option, so I can understand why there would be some confusion as to why mention it in an 'authentication post'.   It's an alternative to giving unique data per user.  Publishers will need to decide what kind of security their content needs.  If they are displaying any kind of sensitive data they shouldn't use unique urls.   We also display to the user the url they are subscribing to in the subscribe dialog so they can make a decision.  For Dynamic Web Slices or Alternate Display Source, we show the url in the preview window since that's not the actual url they are subscribed to.

• Anonymous
  March 17, 2009
  @Amy P: Yes, I'm talking about unique URLs per user. Although you warn everyone about unique URLs being insecure and recommend they only be used for public information, unique URLs often violate these guidelines. Basic auth without SSL is bad, but the same is true for lots of other auth methods. Many sites use login forms that post credentials in plaintext (Twitter). Others use a session cookie which can be sniffed. If you want to guarantee credentials are never sniffed, the only thing I can think of is to require HTTPS. Of course, doing that will make lots of people angry. (I can imagine the ridiculous complaints about Microsoft forcing websites to buy SSL certs.) I understand the trade-off you're making, I just think disallowing basic auth over unencrypted connections is inconsistent with the rest of your security decisions. Speaking practically though, this isn't a big deal. I bet 99% of sites that require HTTP auth use digest. While I'm posting, I might as well point out one other annoyance. From the post: "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. " Why not remember the credentials after the first login? Safari's web clips will auto-login with any credentials in the user's keychain. I should finish on a bright note. It's easy for people (including myself) to criticize anything. The fact that these are my biggest complaints shows what a good job you've done. Nice work.

• Anonymous
  March 24, 2009
  Conheça os diferentes mecanismos existentes para uma experiência segura para Web Slices e feeds. Obrigad

• Anonymous
  April 06, 2009
  a {color : #0033CC;} a:link {color: #0033CC;} a:visited.local {color: #0033CC;} a:visited {color : #800080;}

• Anonymous
  April 19, 2009
  Saiba como adicionar segurança ao desenvolvimento de aplicações com Visual Studio. Assine as mensagens