Backup for IBM Connections communities

An excellent and a bit overdue addition to IBM Connections is better control over backup of communities. We’re not talking fine grained control and integration with e.g. Tivoli Storage Manager but rather backup to and restore from ZIP-files. The asset has been added to the Greenhouse catalog and is described in the New backup & restore tool for IBM Connections Communities post on the Synch.rono.us blog.

Solved my custom TAI issue with WAS 7

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! 🙂

Turning the login procedure for IBM Connections on its head

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:

  1. 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.
  2. 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.
  3. 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:

  1. User tries to access IBM Connections.
  2. 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).
  3. 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.
  4. 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.
  5. If the user did accept the latest EULA we check to see if the user is available in IBM Connections.
  6. 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.
  7. 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.

When the default isn’t enough – creating a new Lotus Connections Files policy

As posted earlier today I had to change the default maximum library size of in Lotus Connections Files to accommodate a particular user. Of course 1 GB (double of the default) wasn’t enough so I created a new policy for that particular user and assigned it. I was very easy as well. Below are the wsadmin commands.

wsadmin<FilesPolicyService.add("2GB Policy", 2097152000)
A policy was added with the new id 584f818a-106c-4343-
8f40-63ceb0ac5c5f .

wsadmin<FilesLibraryService.assignPolicy(
   "1a60c8d1-fc59-41bc-9d89-c266a9709230",
   "584f818a-106c-4343-8f40-63ceb0ac5c5f")
The policy with the id 584f818a-106c-4343-8f40-
63ceb0ac5c5f is now assigned to the library with the id
1a60c8d1-fc59-41bc-9d89-c266a9709230.

Lotus Connections and extending Files Library Sizes

Funny thing at a Lotus Connections customer today. A user was complaining that he wasn’t able to upload a new version of a file into his Files due to size restrictions. After poking around I found out that the user had uploaded 492 mb of data into Files. After poking some more I found out that a maximum library size is enforced based on policy. By default all users are assigned a policy that allows for 524 mb of data hence why he was unable to upload any more data.

To solve it I changed the default policy to allow for 1 gb of data per user (after asking management). This is done using the administrative service API for Lotus Connections which is quite extensive. Below are my steps with the key values in bold.

The steps are as follows:

  1. Initialize the wsadmin environment
  2. Get access to the Files administrative services
  3. Find the user id using FilesMemberService.getByEmail(email) (user id is f631a9d9-07c4-4dcc-b820-1fdaefc4895c)
  4. Find the users library id using FilesLibraryService.getPersonalByOwnerId(id) usig the just found user id (library id is 1a60c8d1-fc59-41bc-9d89-c266a9709230). This also shows the user is controlled by the default policy (policy id 00000000-0000-0000-0000-000000000000) and that he is using 93% of the allotted space)
  5. Edit the default policy using FilesPolicyService.edit(id, name, size) to set a new size of twice the original size)
  6. Refetch information about the users library using FilesLibraryService.getPersonalByOwnerId(id) to see that the new library size has been applied

D:IBMWASprofilesAppSrv01bin>wsadmin -username wasadmin
-password <password> -lang jython
WASX7209I: Connected to process "server1" on node SDKFU016Node01
using SOAP connector;  The type of process is: UnManagedProcess
WASX7031I: For help, enter: "print Help.help()"

wsadmin>execfile("filesAdmin.py")
Files Administration initialized.

wsadmin>FilesMemberService.getByEmail("jdoe@example.com")
{isOprhan=false, email=jdoe@example.com,
directoryLastUpdate=2011-01-04 17:07:57.167,
id=f631a9d9-07c4-4dcc-b820-1fdaefc4895c, name=John Doe,
createDate=2010-02-19 13:04:36.404, communityLastUpdate=2011-01-04
17:12:25.084, lastVisit=2011-01-04 17:07:57.167,
directoryGroupLastUpdate=2011-01-04 17:12:25.084}

wsadmin>FilesLibraryService.
   getPersonalByOwnerId("f631a9d9-07c4-4dcc-b820-1fdaefc4895c")
{lastUpdate=2010-02-19 13:04:36.467, externalInstanceId=null,
id=1a60c8d1-fc59-41bc-9d89-c266a9709230, type=personal,
ownerUserId=f631a9d9-07c4-4dcc-b820-1fdaefc4895c, title=John Doe,
label=24924863-F97C-C455-C125-74C9004077E4, externalContainerId=null,
policyId=00000000-0000-0000-0000-000000000000, createDate=2010-02-19
13:04:36.467, summary=, percentUsed=0.9382985649108887,
maximumSize=524288000, size=491938678}

wsadmin>FilesPolicyService
   .edit("00000000-0000-0000-0000-000000000000",
   "Default Policy", 1048576000)
The policy with the id 00000000-0000-0000-0000-000000000000 was
   updated successfully.

wsadmin>FilesLibraryService
   .getPersonalByOwnerId("f631a9d9-07c4-4dcc-b820-1fdaefc4895c")
{lastUpdate=2010-02-19 13:04:36.467, externalInstanceId=null,
id=1a60c8d1-fc59-41bc-9d89-c266a9709230, type=personal,
ownerUserId=f631a9d9-07c4-4dcc-b820-1fdaefc4895c, title=John Doe,
label=24924863-F97C-C455-C125-74C9004077E4, externalContainerId=null,
policyId=00000000-0000-0000-0000-000000000000, createDate=2010-02-19
13:04:36.467, summary=, percentUsed=0.46914928245544435,
maximumSize=1048576000, size=491938678}

wsadmin>