Missing Security Features in Enterprise RSS Tools
[Note from infoarch: Peter Verhoeven is a smart colleague of mine. One of the things he’s working on is selecting and implementing an Enterprise RSS solution for the company we work for. Peter did deep research on this topic and found some gaps in what current Enterprise RSS vendors are offering. I asked Peter to summarize his thoughts in the guest blog post you find below. Enjoy! And we would love to hear what you think. Peter's LinkedIn profile can be found here and he initiated and maintains a popular website, Magnifiers.org.]
Introduction
Last months we evaluated two Enterprise RSS solutions: Attensa Feed Server (AFS) from Attensa and NewsGator Enterprise Server (NGES) from NewsGator, to replace our self-made Enterprise RSS solution.
Both products are missing an essential feature for us, namely good support of “secured feeds” and options to share “secured feeds” with employees with the same permissions.
What are “secured feeds”?
A “secured feed” can be defined as an RSS feed, that can only be accessed by employees with enough permissions.
Within the company firewall think about an RSS feed on a Sharepoint site, where project members are collaborating.
Outside the company Firewall think about services that need any type of authentication, for example accessing company related RSS feeds on Yammer.
What all “secured RSS” feeds have in common is, that you can access them by entering a valid username and password combination.
Why Use Secured RSS feeds?
The security policy in our company is that you can only see information you are allowed to see.
If for example members of “Project X” are sharing information in a Wiki “Project X” and want information in this “Project X” Wiki to be restricted to members of “Project X”, then employees not working on “Project X” are not allowed to access RSS feeds on the “Project X” Wiki.
Most websites in our company like Wiki’s, Blogs, Sharepoint, the intranet portal, require that you are a member of our Windows Domain.
To access these websites employees must be logged onto our network.
As a result, all RSS feeds on the above mentioned websites, need authentication to access and are secure RSS feeds.
Enterprise RSS Secured Feed Requirement
Two important advantages are frequently mentioned to implement an Enterprise RSS solution within the company, instead of using individual RSS client software:
- Network Bandwidth reduction.
- Improved collaboration by sharing RSS feeds.
This is exactly what we think are advantages of an Enterprise RSS solution, but these advantages should also work for secured RSS feeds, since more than 90% of our RSS feeds are secure.
To explain our requirement regarding secure feeds in an Enterprise RSS solution I’ll give you the simple example below.
Example:
- “Person A” and “Person B” are members of “Project X”.
- “Person A” and “Person C” are members of “Project Y”.
- “Project X” has a secure RSS feed “Feed X”, that can be accessed by “Person A” and “Person B” and not by “Person C”.
- “Project Y” has an RSS feed “Feed Y”, that can be accessed by “Person A” and “Person C” and not by “Person B”.
After “Person A” subscribed to “Feed X” in an Enterprise RSS solution:
- “Person B” and all other members of “Project X” accessing the Enterprise RSS solution, must be able to see and subscribe to “Feed X” in the Enterprise RSS solution (Feed sharing).
- “Person C” and all employees who are not a member of “Project X”, do not see “Feed X” in the Enterprise RSS solution and are not able to subscribe to it.
- If 3 members of “Project X” have a subscription on “Feed X”, the Enterprise RSS solution polls only once for new news items, instead of doing this for any subscribed person (network bandwidth reduction).
“Person C” add “Feed Y” of “Project Y” to the Enterprise RSS solution:
- “Person A” can see and subscribe to this feed, because he or she is also a member of “Project Y”.
- “Person B” does not see and can not subscribe to “Feed Y”, because he or she is not a member of the project “Project Y”.
- All project members of “Project Y” can see and subscribe “Feed Y” in the Enterprise RSS solution (RSS feed sharing).
- “Feed Y” is polled once for all project members of “Project Y”, who have a subscription on “Feed Y” in the Enterprise RSS solution.
Secure RSS feeds in NewsGator Enterprise Server
In NewsGator Enterprise Server (NGES) secure RSS feeds ‘work’ as follows:
- An administrator can add a secure feed to the company taxonomy. By doing this all employees can see and subscribe the secure RSS feed, without using their own username and password.
The advantage of this is that all those secured RSS feeds added by an administrator can be shared (RSS feed sharing) and are polled once for all subscribers with the administrator permissions (Network bandwidth reduction).
This can work for RSS feeds only requiring that you are a member of the ADS Group Domain Members. It does not work for RSS Feeds with a higher security level. - Secure feeds added by individuals, instead of administrators, are not visible by others and therefore cannot be shared. Also the advantage of network bandwidth reduction does not work for these individually added RSS feeds.
If 100 employees individually add secure feed “Feed A” to their subscriptions in NGES, this feed will be polled 100 times and there is no network bandwidth reduction.
Secure RSS Feeds in Attensa Feed Server
And, AFS ‘works’ in this way:
- In Attensa Feed Server (AFS) individuals can add secure RSS feeds. All these RSS feeds can be shared with others.
- When trying to subscribe to a shared secure RSS feed in AFS, the subscription always fails. The only way to get the same RSS feed in your own subscriptions, is by adding the RSS feed by yourself again.
- When clicking on an RSS feed, for which you do not have enough permissions on the source website, you can read the titles of the items in the RSS feed. This is really a lack of security in AFS.
- Network bandwidth reduction does not work in AFS for secure RSS feeds.
Conclusion
Currently, both NGES and AFS do not support our requirement for secure RSS feeds.
Are you implementing an Enterprise RSS solution? How are things going? Have you also run into security issues? How did you address them?
You are confusing authentication with authorization. Just because "A" and "B" are both authenticated and are able to use an application (which produces a feed) doesn't guarantee they are authorized to see the same data.
ReplyDeleteYou are also making the assumption that feeds only contain content (like blog posts). Feeds can also contain information coming from applications.
One way to approach this is think of the feed as a web application that you interact with. For example, a CRM system. Persons "A" and "B" both have access to the CRM system but cannot perform the same functions. Perhaps "A" can look at all outstanding leads but "B" can also look at all closed deals. Therefore, if the CRM system uses the same feed URL "A" will not see some items that "B" does (closed deals).
The reason secured feeds cannot be shared is because they may contain different feed items per user.
Secured feeds are personalized feeds. Now, think about what opportunities that may enable for the enterprise and there you will find potential benefits that go behind simply saving bandwidth. Personalized feeds are individualized signals coming from enterprise applications.
The Newsgator approach to secured feeds seems to allow for the situation in which everyone authorized to use the feed will receive the same content and looks to be a reasonable compromise.
In general I am missing two functionalities in feed readers, inside and outside the enterprise.
ReplyDeleteOne is access to secured feeds. I have access to lots of web based workspaces that have password protected feeds. But a lot of feedreaders simply do not allow you to subscribe to those feeds.
Another is being able to tag feeds (not items in feeds, which a number allow you to do), so I can make more different cross-sections of my feedreader's content. Makes it easier for me to hunt for patterns.
Is tagging feeds (again: not items, but tagging the subscription itself) something that came up as a requirement for your situation?
Hi Larry,
ReplyDeleteFirst, thank you very much for your comments.
You are right that I make the assumption that feeds only contain content (like blog postings) and not individual based RSS feeds like your CRM system example.
In your example there seems to be no need to share RSS Feeds with colleagues or improve collaboration.
I also am curious what Enterprise RSS solutions such as NewsGator Enterprise Server and Attensa Feed Server, will give you more than E-Mail in this case already can do?
I describe a situation with a growing volume of information within our company, and employees who have problems to find information relevant for them.
We think that by sharing RSS Feeds, employees need less time to find information.
Everyone can see what his or her colleagues within the department or speciality are reading.
Because more than 90% of our internal RSS Feeds are secure, we think an Enterprise RSS solution should support this.
If we only can share RSS Feeds outside the company, we can also use Google Reader for external RSS Feeds (what a lot of employees are doing now) and an Outlook plugin like RSS Popper to read internal RSS feeds.
Hi Peter,
ReplyDeleteI'm a product manager at NewsGator. Thanks for the detailed look at NGES. Security is always a top priority for us, and we always try to take the most secure approach first. That is why in most cases we make access to certain feeds as private in the base case. Unfortunately, you are looking at only one environmental scenario for access to secured content -- one where the user/admin enters a username and password directly against the feed in NGES.
To address the scenarios above, we've found that the customer environment drives the solution. There are at least two environments that I'd like to point out where we can accomplish the scenarios above. First is when a customer has implemented Kerberos, and the other is when they are using SharePoint.
In the Kerberos case (typically SharePoint actually), we will retrieve the information from the feed based on the authorization provided by the Kerberos ticket.
The SharePoint case is actually divided into two other situations -- one, where the user is accessing the list information outside of SharePoint (ie. in a NGES reader); two, where the user is accessing list information from a NewsGator Social Sites web part from within the SharePoint security context. In either case, we can support secure access to commonly subscribed feeds. The best case is when we access the lists from within SharePoint through our views through NewsGator Social Sites. Each view is security trimmed based on the user's authorization to the content contained within the feed/list. Outside of SharePoint, we take a more conservative approach.
Finally, there are other scenarios using other SSO technologies like Siteminder to handle these cases.
If you'd like a more detailed discussion on our security capabilities, I'd be more than happy to arrange that!
Again, thanks for the blog.
I posted some details on my blog as to NewsGator's secure feed implementation, along with the recommended way to address the issue you're seeing:
ReplyDeletehttp://www.rassoc.com/gregr/weblog/2008/12/17/enterprise-rss-and-security/
Peter,
ReplyDeleteI just posted a response to your question regarding the use of secured RSS feeds versus e-mail here: http://ccsblog.burtongroup.com/collaboration_and_content/2008/12/secured-rss-versus-e-mail.html
Larry
Have you had a look at the Apache Abdera project?
ReplyDeletehttp://abdera.apache.org/
This comment has been removed by a blog administrator.
ReplyDeleteGreat blog... web template
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete