IntraVision is happy to offer a fixed price IBM Connections Kick-Start offering to get you started with IBM Connections per the entitlement offered by IBM as part of the Notes 8.5.3 maintenance release. At our Social Business event on Thursday 27 October (there’s still time to register) we will be happy to discuss this offering as well as our new OnTime for IBM Connections product with you. More information about event may be found as part of our online newsletter (linked below).
(Of course) Stuart beat me to the punch but I wanted to blog it anyway.
Today IBM officially announced the IBM Connections Extensions Authorized User license as an easy (and inexpensive) way to buy the rest of the IBM Connections suite of features if a customer is making use of the entitlement for Connections Files and Connections Profiles granted as part of Lotus Notes 8.5.3. I too think this is a great move by IBM but asks the question how I’m going to control what parts of Connections users use if running in a mixed environment where some users are using Connections as entitled through Notes and some use it by virtue of their full license. In Sametime we have policy controls to help us but we do not have that in Connections nor have I heard any mention of it. I guess we will have to see how to approach this and whether it becomes an issue at customer sites.
Anyways still a very nice and clever move by IBM.
Starting with IBM Connections 3 the Websphere wsadmin command is even more important as the only way to deploy Connections is using Websphere Application Server Network Deployment or ND for short. The wsadmin command is used to check out the Connections configuration files and check them back in after modification. Because some commands require different configuration services to be loaded I have started compiling a cheat-sheet of some of the commands one use all the time. I have created a page for them. Expect the list to grow over time.
Of course the Info centers and wikis also list the commands.
I’ve previously blogged about the goodness of Trust Association Interceptors in Websphere Application Server (WAS) and how I’ve used it to turn the login procedure for IBM Connections on its head. We recently started upgrading the customer I originally developed this for to IBM Connections 3.0.1 hence they needed an upgrade to WAS 7. After upgrading the WAS servers the custom TAI didn’t work anymore. The TAI loaded just fine but it didn’t generate the needed LtpaToken2 for the visiting user. I cried out for help in the Connections forum. I got a few pointers but none of them helped me.
Fortunately I figured it out tonight.
The issue was that my custom TAI created subjects (a subject is the entity that holds the identity of the authenticated user in WAS) in a custom realm that wasn’t trusted by WAS. The only trusted realm was the one that WAS created for me when I configured Federated Repositories. The solution was to add the custom realm as trusted under Federated Repositories, configure <my realm> and then go to “Trusted authentication realms – inbound”. The entry is at the bottom under “Related Items”. Here I simply added my realm as Trusted, restarted WAS and I was golden!! Again this wasn’t necessary in WAS 6 and actually the option isn’t there at all in ISC.
Now I’m back to thinking that WAS and TAI’s are the best thing since sliced bread! 🙂
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.
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.
This weeks SnTT post is about Lotus Connections and how to more easily get access to and change the translation files for the UI of the Profiles feature.
Configuring which pieces of information are surfaced in the Profiles feature is pretty easy and well documented using the profiles-config.xml file. Changing the label text however is harder and not that easy to do. As it is documented it involves stopping profiles, locating a jar-file, extracting it using WinZip, changing a properties file, repackaging the jar-file, redeploying the jar-file and finally restarting profiles to see the change. This is well and good and acceptable if you only need to change the file once, but chances are that it’s an iterative process and you need to do it multiple times. Wouldn’t it be easier to simply stop profiles, change the file and restart profiles? Well read on to see how.
The labels for the fields (and all the other pieces of text for that matter) in Profiles are stored in property files in a jar-file in the Profiles application. Changing the property files for the appropriate language causes the text to change in the UI after a restart of the Profiles application. This is easy enough but require a lot of repeated steps every time since you have to unpack the jar-file, change the property file and repack the jar-file.
Since Profiles is just another Java web application we can move some of the classes and property files out of the jar-file (in the “lib”-directory) and into the “WEB-INF/classes”-directory. This means that we only have to repack the jar-file once and for all since the property files are now available from the “classes”-directory.
On your Websphere Application Server where the Profiles feature is installed (with Profiles stopped) do the following using a file explorer:
- Open the profile directory for the profile you’re using
- Open the installedApps directory and the node directory underneath it (chances are that there’s only one node directory)
- Open the Profiles.ear directory
- Open the peoplepages.war directory
- Open the WEB-INF directory
- Create a new directory called “classes”, and inside this directory create a com/ibm/peoplepages/webui directory (a total of 4 directories)
- Open the lib directory and locate the peoplepages.web.jar file and make a backup copy of this file
- Now unzip the jar-file (maybe renaming it to a zip-file first), navigate through the directories to com/ibm/peoplepages/webui and move the resources folder to the “classes/com/ibm/peoplepages/webui”-directory you created above
- Navigate back to the extracted jar-file and zip the “com” and “META-INF” directories back up into peoplepages.web.jar and overwrite the peoplepages.web.jar file you located in step 7
Now you should have replaced the original peoplepages.web.jar file with a new one and have a directory containing the resource files.
Now when ever you need to change a label for a field simply locate the label or text you would like to change in the property files underneath WEB-INF/classes/com/ibm/peoplepages/webui/resources and restart Profiles.
Please note that the above probably isn’t supported by IBM… 🙂