Xobni Sets Its Sights on the Enterprise

I’ve been waiting for this one for awhile. I’m a fan of Xobni and have found it to be a useful addition to my Outlook inbox. I have enjoyed Xobni’s integration with Facebook, Twitter, and LinkedIn. I find it interesting, if not useful, to quickly see what the person who sent me an email has had to say in the social realm. It helps me understood who they are, etc.

Despite Xobni integration with these tools they lack integration with other key technologies that I use on a daily basis…like Microsoft SharePoint. Also, Xobni has not been an open platform for developers. SDK and other tools to allow developers to extend Xobni have not been available…until now.


Xobni Enterprise

Xobni enterprise provides organizations with the ability to deploy the Xobni Outlook client and centrally manage the features available to employees. The server component is accessible through an admin web site. Via the admin portal, you can control deployment to groups of Active Directory users. You can also activate/deactivate Xobni Enterprise features.

Xobni Enterprise includes features for end-users as well. For example:

  • AutoSuggest
  • Advanced Filtering
  • Unlimited PSTs
  • Appointments and Tasks

Xobni Developer SDK

With Xobni Enterprise arrives a Xobni SDK for anyone that wants to extend Xobni. From reading their press release, it looks like integration with just about any type of application will be possible.

Novell single sign-on adds SharePoint support

Active Directory is the identity store for authenticating users to Microsoft Office SharePoint . WS-Federation is typically supported only in more expensive, ..

Read more from the original source: 
Novell single sign-on adds SharePoint support

Open Source – “Because we can fix it if it breaks”

My current project at the time involved building a Single Sign-On architecture. A key requirement for the project was it had to provide capabilities for sending and receiving SSO requests to and from their partners.
We, (my team at Cogent Company) had it all mapped out using Windows Server along with Active Directory Federation Services (ADFS). We even found a great partner that could handle the integration of Windows with other platforms (i.e. IBM, SUN, Linux/Unix, etc.).
Our best laid plans were soon changed when we started working with my client’s partners. They decided against implementing our architecture (which would require minimal changes to their code base) in favor of open-source technologies. One partner’s justification for their decision was, "because if it breaks, we can fix it".
Nice. If only their boss could have this rationale. What manager or executive wouldn’t want their people fixing open-source software?  I wonder how this situation would play itself out in actuality? In their status report would they cite as their reason for not completing their work as, "unavoidable delays caused by the need to correct open source the open-source application we chose that doesn’t work?"
I realize this attitude is not shared by everyone who prefer to use open-source technologies. But in my experience I have run into enough to decide this attitude is just plain stupid.
Why not just implement something that works once deployed and is backed by a real company…not a bunch of techno-wizards that like to experiment with their  code?