Presentation from ISBG: An Introduction to Working With the Activity Stream

Below are my slidedeck from my Activity Stream presentation at ISBG.

[slideshare id=21817349&w=427&h=356&fb=0&mw=0&mh=0&style=border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px&sc=no]

Authentication vs. Authorization

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 given resource we actually talk about two related concepts which are always performed – 1) authentication and 2) authorization.

Authentication is the process by which we authenticate the user i.e. find out that the user is authentic and is who he or she claims he or she is. This is most often done using a username and a password but there are numerous ways of doing this. The authentication step is most often followed immediately by authorizing the user to perform a certain task or access a certain resource. A user may be authenticated but not authorized i.e. we know who the user is with certainty but the user is not allowed to perform the operation or access the resource he or she set out to perform or access. A user may also be authorized without being authenticated in which case we allow an non-authenticated user (e.g. Anonymous in IBM Domino) to have certain rights in the system. The latter is the case where an Anonymous user is allowed to open a database, browse a web site etc.

The failure to distinguish between these two steps can lead to a lot of SSO issues and errors not being easily understood and/or debugged. Consider the case where a user signs into System A (i.e. authenticates and the user account authorized to perform the task at hand) and then moves on to System B to access another resource or perform a task which the user is “suddenly” unable to perform. Why? The user was able to work in System A so why not in System B?

This is the time where the person debugging this should stop and think…

Is the reason not because the user isn’t authenticated but because he or she isn’t authorized? Could it be that the user is authenticated both by System A and System B but that System B wasn’t able to authorize the user? Maybe because the username was in another format or the particular username permutation not listed in the ACL or group authorizing the user to work in System B. Knowing about the steps performed can make it a lot easier (or just possible) to diagnose.

Using a good old Notes database with a wide open ACL and a simple page displaying the username of the current user (i.e. using @UserName in a piece of computed text) can make all the difference. It easily shows issues with the user being known by a LDAP username (e.g. cn=Mikkel Flindt Heisterberg,ou=Users,dc=intravision,dc=dk) and not by a Domino distinguished name (CN=Mikkel Flindt Heisterberg/O=IntraVision) or SSO not working due to misconfigured domain names, no shared secrets etc. by the user being known as “Anonymous” because the LtpaToken(2) was never sent to the server due to the cookie rules not being fulfilled. Same goes for Websphere Application Server – a simple WAR based application with a servlet displaying the current username is great for debugging.

Hope it clarifies matters and is helpful to someone.

Websphere Application Server WIM LDAP adapter log trace

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.

Setting up LDAP failover for Websphere Application Server

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 – see Websphere Application Server Security – make sure file based auth continues if federated repository is unavailable) 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 set some additional parameters. The screenshot below shows a secondary LDAP server added to the ISC.

Editing wimconfig.xml (see the wim/config-subdirectory of the cell configuration directory e.g. c:wasprofilesdmgrconfigcellsLCCell01wimconfigwimconfig.xml) is easy as well. You simply add an additional LDAP server to the config:ldapServers tag as shown below. The parameters in bold can be used to make sure that WAS return to the primary LDAP server (first listed) and optionally what the poll time should be (in minutes).

<config:ldapServerConfiguration primaryServerQueryTimeInterval="15"
   returnToPrimaryServer="true"
   sslConfiguration="">
   <config:ldapServers authentication="simple" bindDN="cn=LDAP User,o=Example"
      bindPassword="{xor}removed :)" connectionPool="false" connectTimeout="0"
      derefAliases="always" referal="ignore" sslEnabled="false">
      <config:connections host="cph001.intravision.dk" port="389"/>
      <config:connections host="cph002.intravision.dk" port="389"/>
  </config:ldapServers>
</config:ldapServerConfiguration>

Full info in the info center under Primary and secondary LDAP server failover.

Looking up a datasource from an IBM Connections event handler

For a customer project I’m working on these days I’m writing an event handler for IBM Connections Profiles to integrate two profile systems in real-time using the IBM Connections 4.0 Event SPI. Pretty powerful stuff in case you’ve never looked into it.

In IBM Connections an event handler is basically just a Java bean which you register in events-config.xml to be called when certain events occur such as a profile being updated, the photo set, the photo removed etc. In this event handler I needed to contact the Profiles database which should be easy as it’s registered in JNDI in Websphere Application Server. I couldn’t however use the usual java:comp/env/jdbc/profiles resource reference as there’s no J2EE deployment description for the event handler and hence the naming context hasn’t been mapped for me.

But with Websphere Application Server being the all-purpose application server that it is, I was able to find a way to make it work anyway. It turns out that all resources are mapped into a JNDI namespace using their cell and cluster prefix as well (I was able to deduce it from the “Example: Looking up an EJB home or business interface with JNDI” page).

So to look up the jdbc/profiles data source from the Cluster1-cluster scope I simply use the following. Sweet.

try {
   InitialContext ctx = new InitialContext();
   DataSource ds = (DataSource)ctx.lookup("cell/clusters/Cluster1/jdbc/profiles");
} catch (NamingException e) {
   // unable to lookup data source
}

Fixing IBM Connections help for IE users

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 simpel using a “sledgehammer approach”. I simply used one of the cool modules in IHS (Apache) to add a compatability header to force all document into IE7 mode.

Below are the steps – YMMV.

  1. Open your httpd.conf file for edit
  2. Uncomment the mod_headers module near the top by removing the hash-character at the beginning so the line simply reads “LoadModule headers_module modules/mod_headers.so”
  3. At the end of the file simply paste in the following command
    Header set X-UA-Compatible IE=7
  4. Save and close the file
  5. Restart the IHS

Hiding the Social Mail username and password from socialmail-discovery-config.xml

It’s been bothering me a while that the username and password for our LDAP user was visible in clear text in our socialmail-discovery-config.xml. After going looking for a solution by using very specific searching I found a solution where you can hide the username and password and – stupid as I am – it’s actually right there in the install docs. Stupid is as stupid does. The solution is to remove the authentication data from the socialmail-discovery-config.xml and replace the <DirectoryUser> and <DirectoryPW> tags with a single <DirectoryAuthAlias> tag. This tag should reference a J2C alias configured in the Websphere ISC. Simple and effective.

The above solution is for Domino only – if you’re using Exchange mail you need two additional tags. For complete instructions on the tags refer to the wiki at Enabling the discovery service for IBM Connections Mail.

There’s a new sheriff in town

Last week was the annual BLUG event this time in Leuven, Belgium, and as always Theo and team created an amazing event. The BLUG event is now the biggest user group in the a World with a staggering 325 attendes and it really makes BLUG a mini-Connect event attracting the top names from IBM as well as the top speakers from all over the World. This year was no exception and the attendees were gifted with 18 IBM Champions covering everything from Domino to Websphere, XPages to widgets and social to taxonomy. It was a great event.

Now as the title might suggest this post is not about BLUG per say.

One of the super cool things about the user groups (besides being FREE, FREE, FREE) is that IBM Collaboration Solution (ICS) is really stepping up to the plate. They are sending their top guys and this year was no exception. Among others we heard from Philippe Riand, Pete Janzen and Scott Souder who had made the trip across the Atlantic. Ed Brill also made a surprise appearance to talk about and promote the IBM MobileFirst initiative which he’s now evangelizing. Now these aren’t just anybody as these guys really are calling the shots when it comes to Notes, Domino, iNotes, Connections Mail and social appdev in Boston so if you had something to say to these guys at Connect 2013 and missed your chance because the IBMers just aren’t accessible at Connect this was your chance.

As always a big THANK YOU! to all the IBM’ers for making the trip and making themselves available to the European community as well. Thank you.

Now to the sheriff thing…

Scott is really the new Ed (who he jokingly referred to multiple times during the keynote) and thus the Program Director for Notes / iNotes / Connections Mail so he pretty much calls the shots across the board. And what an entry he made. Giving one of the best keynotes by an IBM’er I remember seeing (sharing the limelight with Louis Richardson) he really kicked the event off with a bang. He managed to introduce himself formally to the community, set the stage for the new IBM Notes / IBM Domino 9 release (released on the day of BLUG) and honestly talk about the road ahead and the changes IBM are making to “dumb down” the product.

So to finish off the sheriff metaphor, Scott securely took the reins and stod up in saddle for all to see. It was a great talk, great appearance and I’m very confident that IBM has found a great guy who really knows and cares about the products we all love and who has the ability to lead the teams forward.

As to the keynore I know Chris Miller had his camera out at the keynote and I’m pretty sure he filmed it so if/when it makes it online I highly suggest you watch it.

Calendar integration example using OnTime Group Calendar API

The Problem

A Danish insurance company was running a CRM system to control and maintain customer relationship information and plan meetings for its insurance agents. Because the CRM system wasn’t integrated with their IBM Domino infrastructure running their mail and calendar the insurance agents in effect had two calendars – one in IBM Notes holding their company appointments and one in a CRM system holding their external customer meetings. This meant that the insurance agents effective stopped using their calendars or maintained a third, non-company, calendar) as there were no single place to see all appointments. Besides this the organization as a whole was unable to plan internal meetings with the insurance agents as their calendars didn’t reflect their actual whereabouts.

The Solution

To remedy this they decided to use the OnTime Group Calendar API to integrate the two systems using web services using an intermediate Enterprise Service Bus (ESB). The OnTime Group Calendar API web services are hosted directly on IBM Domino and performs extremely well. After implementing the solution the insurance agents only need to maintain their calendar in Notes as it will reflect their true calendar showing both internal, external and personal appointments and meetings.

The solution provides a true two-way synchronization so any appointment planned from their CRM system shows up in the calendar in Notes. If the user reschedule the appointment the corresponding appointment in CRM is automatically updated and if the appointment is deleted the appointment get cancelled in the CRM system as well as a follow-up activity being created to make sure a new meeting is planned. The personal calendar in Notes is also updated once a meeting is marked completed in the CRM system to allow for automated expense reporting based on the personal calendars in Notes. As an added benefit of the using the OnTime Group Calendar API all insurance agents are now able to use their Notes client, their iNotes webmail or their mobile device to do their job resulting in true mobility and added flexibility.

Below is an architectural drawing showing how it all integrates using Domino as a central application server.


(click image for a larger version)