In the latter part of last year I was involved in installing IBM Connections at a customer site for initially 20.000 users and then, if all went well, for the full 70.000 users. The challenges in evangelizing the solution and getting people to use it is for another blog post but the project is interesting from other perspectives as well.
Firstly they wanted to change the layout of IBM Connections and add their own colors etc. which wasn't a biggie. Next they wanted to change certain core words within IBM Connections. In Danish the word for "Communities" is "Fællesskaber" but they wanted it to be "Grupper". Changing that throughout IBM Connections was a hazzle and we have to migrate these changes by hand when we upgrade to version 3 but it was possible which is the good story here. The last one was the biggest requirement and the the requirement it took the most work to satisfy. They wanted to turn the entire login process for IBM Connections on its head.
So what do I mean by that?
By default IBM Connections works by you importing all valid users into the Profiles database using TDI or a handcrafted tool and then hooking Websphere Application Server up to LDAP. They didn't want that and the users actually didn't exist in a LDAP directory but instead in another (Domino based) member database.
They had a number of requirements:
IBM Connections should work with their existing single-sign-on (SSO) solution which supported a number of different login methods incl. two-factor and digital certificates.
Before being granted access to IBM Connections the user should accept an End User License Agreement (EULA) and if not the user should be denied access to IBM Connections.
Users wasn't allowed to be available in IBM Connections before opting in to using it by accepting the EULA i.e. they didn't want users in the Profiles database before they had accepted the EULA.
The access procedure they wanted may be illustrated as below.
(click the image to a larger version)
So what does an IBM Business Partner do? Say "Sorry that isn't possible" and "That's really not the way that IBM Connections work"? Well of course not because it was and is possible due to IBM Connections being built on top of Websphere Application Server which is an open and highly extensible platform.
The key piece to the puzzle is a piece of technology called a Trust Association Interceptor - or TAI for short - and is a way to change the way Websphere handles authentication and how Websphere normally integrates with reverse proxies such as WebSEAL.
A TAI is a Java class written to a specification (interface) from IBM and very easy to write. The functionality may of course be complex but the way you integrate with Websphere Application server isn't. Once the TAI was written and installed into Websphere Application Server the customer now has an access procedure like this:
User tries to access IBM Connections.
If the user isn't logged in using the 3rd party SSO solution the user is sent to the login screen (1 in the diagram above).
If the user is logged in (and tokens are still valid) an EULA check is performed to verify that the latest EULA has been agreed to.
If not the user is sent to the EULA system (2 in the diagram above) to accept the EULA instructing the EULA system to return the user to IBM Connections afterwards.
If the user did accept the latest EULA we check to see if the user is available in IBM Connections.
If the user isn't in Profiles yet the user is sent to the Populator system (3 in the diagram above) that handles collecting using information and populating Profiles. Once completed the user is returned to Websphere Application Server.
If the user is in Profiles already the user is granted access to IBM Connections (bottom on the diagram).
It sounds complex but it's done in less than 500 lines of code incl. comments and documentation. That isn't too bad is it? What's really cool is that it allows for some very exciting ways to integrated IBM Connections into existing environments.
I'll post more about TAI's over the next few days about how you write them and more about the technical underpinnings. Stay tuned.
WebSphere Application Server Liberty Profile webcast replay
Wed, Aug 6th 2014 10:47p Mikkel Heisterberg In case you haven't heard about WebSphere Application Server Liberty Profile and you are doing any work with J(2)EE servers you really should do your self the favour and read up on it. In essence it's the best thing since sliced bread for application developers that target WebSphere Application Server and here's why:
It downloads and installs in less that 5 minutes
It's binary compatible with the full WebSphere Application Server so you can be certain that code that runs on Liberty Profile [read] Keywords: ibm
Mon, May 12th 2014 12:38p Mikkel Heisterberg I'm deeply saddened by the news that Tim Tripcony has passed. There are very few people that I as a programmer / coder look up to, who inspire and impress me and who I admire. Tim was one of those and now I'll never get to admit it to his face.
R.I.P. Tim. [read] Keywords:
Installing TDI v. 7.1 on Windows Server 2012
Wed, May 7th 2014 4:00a Mikkel Heisterberg Trying to install IBM Tivoli Directory Integrator (TDI) v. 7.1 for IBM Connections on Windows Server 2012 I got the following error:
ZeroGu2: Windows DLL failed to load
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.inv [read] Keywords: connections
It's been a while!
Fri, May 2nd 2014 11:51a Mikkel Heisterberg Wow! Blogging hasn't really been my thing for a while. Actually I realize that I've flow a bit below the radar for the last couple of months. November saw the birth of our second child (a son, Matheo) and we're still adjusting a bit to the life as a two-kids family though it's getting easier. I sure enjoyed going to Summer Time this year as it means that he wakes up at 6am instead of 5am. Besides that 2013 ended in work, work and preparations for Connect 2014.
IBM Connect 2014 is still kin [read] Keywords: connections
Writing command line scripts with node.js
Mon, Feb 17th 2014 11:20p Mikkel Heisterberg Found this little tip this morning to make it easier to use command line scripts written in node.js. Instead of having your node.js file(s) and invoking it using "node myfile.js" on the Mac you can simply do the following:
At the top of the file as the first line add: #!/bin/usr/env node
Make the file executable using chmod +x myfile.js
Now the file is usable by simply using myfile.js. [read] Keywords: mac
Year in review 2012 (not a typo)
Tue, Dec 31st 2013 5:12a Mikkel Heisterberg Boy 2013 was a busy year. In fact it's been so busy and I have been so bad at blogging that I never got around to finish my year end review for 2012. In a draft blog post I had the following:
"2012 was a busy year - maybe the busiest year I've had in a long time. Besides numerous customer projects here in Denmark I've also been involved in a number of international projects and traveled more than ever before. I went to the US twice, Japan twice, Australia once, and to too many European cou [read] Keywords: connections