As you might recall we at IntraVision some time back quit running Lotus Sametime on-premises and switched to LotusLive. This wasn't without issues and I also blogged about the apparent lack of public groups in my "Using LotusLive for Sametime - 2 months in" post a couple of months ago. After experiencing this issue I talked to Erik Vos from RealConnections in the Netherlands at NLLUG. Erik was also having the same problem for his SaaS customers so we worked together to develop a proof-of-concept Notes sidebar plugin called Stommunity to work around the issue. The name Stommunity plays on the words Sametime (ST) and (LotusLive) Community.
So what does the plugin do?
The plugin synchronizes your LotusLive communities with your Lotus Sametime client and creates private groups based on the LotusLive communities you are a member of (and that you select for synchronization). This mimics the missing public group feature of LotusLive Sametime. The below screenshot shows a Sametime client with 4 communities synchronized from LotusLive.
So how does the plugin work?
The plugin sits as a sidebar plugin in your Lotus Notes client and monitors your Sametime client for when it logs into LotusLive Sametime. Once a login is detected it reads the communities the active user is a member of using the LotusLive REST API and shows a list of the communities. The user may then select the communities to synchronize with Sametime. The below screenshot shows the Stommunity plugin waiting for the user to log into Sametime.
Once logged in the communities is read from LotusLive. In the below screenshot you can see that the user is a member of a couple of communities but only one is synchronized with Sametime.
After selecting an additional community and clicking Apply the community is synchronized to Sametime and a private group is created. The below screenshot shows the Sametime client after synchronizing the BlueExtend community with the Sametime client.
So why only a proof-of-concept and not a ready-to-roll plugin?
While developing the plugin we discussed the license implications of a plugin like this. When you sign up for LotusLive Engage you receive a Sametime Entry license which means you may not use the Sametime API which again means that a plugin like this cannot work (from a licensing standpoint). That alone made the project a dead-end and after working a bit with IBM on this it became clear that changing the licensing agreement wasn't in the books. Due to this we are releasing the plugin as a proof-of-concept with open source on OpenNTF hoping that it may inspire someone.
Looking at the plugin as it is now I see a lot of potential. Of course the selection of communities needs to be pushed into the preferences but as a LotusLive customer it would be really cool to have. I imagine an auto-sync option being added as well as an option to just sync all and change (or remove) the prefix I automatically add now ("LL Community:"). Think of having a policy option to automatically make certain, company wide, communities be synchronized to all users (or a set of users). Maybe even controlled from within LotusLive. Now that would be cool and bridge the gap between the products. One could even argue that a plugin like this should be a standard component that should come bundled with LotusLive Notes.
Anyways - I hope it may inspire the LotusLive teams.
The Stommunity plugin may be found on OpenNTF.org and the code may be downloaded from the SVN repository. See below for links to each.
Authentication vs. Authorization
Wed, May 8th 2013 7:39a Mikkel Heisterberg When ever I talk to customers and partners about single-sign-on (SSO) and the concepts of "authentication" I'm quite often baffled by the level of misunderstanding, misconception and lack of knowledge about just how "authentication" works. Now the reason I put "authentication" is quotes is that when we talk about authentication it's really not just authentication we're talking about. When we talk about confirming the identity of a user and confirming that the user is allowed to access a [read] Keywords: acl
Websphere Application Server WIM LDAP adapter log trace
Thu, May 2nd 2013 12:50a Mikkel Heisterberg When debugging LDAP login issues for Websphere Application Server (WAS) you're actually debugging the WIM (Websphere Identity Manager) part of WAS. The actual login piece is part of the adapters (database, ldap, file) which is the repository specific piece that WIM delegate the actual authentication to. The best debug string to use is "com.ibm.ws.wim.adapter.ldap.*=finest" as it limits the debugging to the LDAP piece of WIM. [read] Keywords: ibm
Setting up LDAP failover for Websphere Application Server
Wed, May 1st 2013 2:16a Mikkel Heisterberg As you may know LDAP is crucial to Websphere Application Server (WAS) when using it for IBM Connections so it makes good sense to configure failover for LDAP. If the LDAP server becomes unavailable you can no longer log in (actually you can't even log into ISC) and WAS can have a hard time reconnecting to the LDAP. Failover is set up using either the ISC Federated Security UI or by editing wimconfig.xml directly (or using wsadmin commands). Using wimconfig.xml have some advantages as you can se [read] Keywords: connections
Fixing IBM Connections help for IE users
Mon, Apr 15th 2013 5:13a Mikkel Heisterberg At a customer site they were actually using the IBM Connections help documents (a first I know) but it didn't work for the users in Internet Explorer. After some research it turned out to be due to a missing compatability statement in the generated HTML documents (this statement is present in HTML generated for other features). I've previously reported this issue to IBM but it still hasn't been fixed in version 4.0 CR3 so I took it upon me to find a solution. The solution turned out to be sim [read] Keywords: connections