Sep 29 2006
RSS has grown up on the public Internet and it seems that authentication will be problematic when it moves into the Intranet. On Intranets expect to find the following authentication mechanisms:
- Forms based
- Basic (usually combined with SSL)
Only the last of these mechanisms can be assumed (with any confidence) to work with most desktop RSS readers and often web based readers often don’t even support that.
The essential issue is that the web pretty much assumes that we can cope with all of these authentication mechanisms because all access is interactive, but with RSS it needs to be automatic and transparent. The following issues spring to mind:
- NTLM – so far as I know is only supported by IE 7 and the Vista RSS platform and very few servers, but if you are a Microsoft shop and are only connecting to SharePoint 2007 then this may work for you
- Kerberos – same as above, but probably even more demanding
- Digest – hardly ever used in my experience, either on client or servers, but I may be wrong and has the disadvantage that your username and password will need to be stored somewhere on the client, and many enterprise security policies don’t allow that
- Forms based – very popular server side, but no chance of supporting this in everyday RSS readers. I have seen a hack which involves browsing to a web page from within the RSS reader, authenticating, getting the cookie and then synchronising your feeds. VERY VERY messy
- Basic with SSL – very widely used, supported by most readers and RSS servers, but has the disadvantage that your username and password will need to be stored somewhere on the client, and many enterprise security policies don’t allow that
This leaves us with a problem. If you are a Microsoft shop you might get away with a combination of 1,2 and 5. If not then it looks like it’s time to start lobbying your security policy makers to allow Basic over SSL and local (encrypted) credential storage.