Peter Verhoeven wrote an article a few days ago talking about security features he feels are missing from Enterprise RSS tools, including NewsGator Enterprise Server. I wanted to address his concerns directly, explaining exactly why NGES handles secure feeds the way it does, and talk about how specifically one could address the issue he brings up.
So first, let’s discuss the general case where no security is involved. If user A and user B both subscribe to publicly accessible feed X, the feed content is the same for both – so there exists only one copy of the feed in the system, and everyone sees that same copy and the contents therein. This is highly efficient for all systems involved.
Now on to the slightly more complicated case. When NGES encounters a secure feed (more specifically, a feed which requires user credentials to access), it treats the content from the feed as secure. When user A retrieves feed Y using his credentials, the contents will be stored specific to user A. When user B retrieves the same feed Y but using her own credentials, the contents will be stored for user B. So now we essentially have two copies of the feed.
Why, Greg, why would you do this? It’s the same feed, so you should only store it once. Right?
As it turns out, the answer it no. The issue is that NGES has no way of knowing if feed Y will return the same content for every user that has access to it. Just because the feed URL is the same, doesn’t mean user A and user B will see the same thing when they retrieve it using their own credentials. So, the system stores the content separately.
“Shared” secure feeds
Ah, but now we get to the heart of Peter’s issue. He has a case where he _knows_ the content for a given feed will be the same for every user that has access to it. The problem is, Peter knows, but NGES has no way of knowing.
The only part of the system that could possibly know this is the publisher of the feed – because it’s the application generating the feed, and it knows whether it would generate the same feed for everyone that has access. But it’s a valid case – there are indeed situations where the publishing system knows this is the case.
So, in NGES 3.x, it will actually look for a specific header in the feed that basically says “this feed will be the same for everyone.” If it sees that header, it will still individually authorize access for every user trying to access the feed, but it will only retrieve and store the content once. So essentially, authentication and authorization works the same way – we are just making the behavioral assertion that the content in the feed may be shared among the group of people who have access.
[note: I’ve slightly simplified here, but this is very close to what is actually required.]
This code was initially written to optimize some of the content-retrieval that goes on with our SharePoint-integrated Social Sites Enterprise product…but there are definitely use cases for this feature beyond just SharePoint.
Isn’t the fundamental problem url abuse? If a feed returns different data (i.e. a different resource) depending on who is accessing it, it should provide a different url for that resource. E.g. instead of just ‘/feeds/toiletblog/’, it should be ‘/feeds/toiletblog/jplumber’ etc.
@Gavin – perhaps, but not in every case. For example – if you and I both go to gmail.com, it’s the same URL, but we’re going to see different content. The same is true for any given resource that requires authentication – it’s not guaranteed to be the same for all users.
A more enterprisey example might be a given list in SharePoint – perhaps all users have access to see the list (and thus the feed for the list), but only members of the “Accounting” group can see one extra article in that list. Same URL, but different content.
Thanks a lot for addressing my concerns about missing security features in Enterprise RSS tools.
“So, in NGES 3.x, it will actually look for a specific header in the feed that basically says “this feed will be the same for everyone.” If it sees that header, it will still individually authorize access for every user trying to access the feed, but it will only retrieve and store the content once.”
In terms of functionality, this seems to be exact the feature we request.
In terms of technical implementation I’m curious, how the “this feed will be the same for everyone.” header can be added?
If this can be done within NGES I think it will be a great new feature to share secure RSS feeds.
@Peter, it’s done with HTTP headers in the feed response. I’ll follow up with you via email.
Are the secure RSS feeds in NewsGator Online handled the same way as your enterprise system? I ask because I’d like to use NGO to replace Google Reader it lets me access the fxphd.com forum RSS feeds. However, the fxphd folks are conserned about the secruity of their data in any on-line news aggregator.
Can you comment on this thirt party RSS security question in NewsGator Online. (I’ve posted this question in the forum also.)
Rob: I have a blog post here:
which describes how NewsGator Online behaves with feeds that require credentials. Bottom line, as long as you don’t try to put the credentials on the URL, and as long as the feed actually requires credentials (as opposed to a “secret URL”), it should be fine.