While part 2 was about IBM Connections Mobile this post will be about security and the “coherent-ness” of the platform.
IBM Connections runs/builds on IBM WebSphere Application Server (WAS) and much of the functionality is delegated to the underlying application server. Delegated responsibility is topics ranging from messaging to SMTP transport to database access and security. WAS also handles the clustering and fault tolerance and does it very well. Being built on WAS is a good thing for stability and security but it also has its drawbacks when it comes to manageability and how coherent the application feels.
But lets face it – when I buy IBM Connections I buy just that and not the underlying WAS platform. WAS only adds to the complexity. But since it’s built on WAS many features are leveraged from there many features feels clunky and like they are not part of the application which I guess is right as it technically isn’t. This becomes even more apparent from a security and manageability perspective.
WAS Integrated Solutions Console (ISC) provides a graphical environment to managing certificate trust, configuring directories for authentication and mapping users and groups to Java Enterprise Edition (EE) roles. But Java EE was never really meant to make sense across multiple applications. Everything in Java EE centers around the monolith application where as IBM Connections – the application – is really made up of many many Java EE applications. In v. 1.0.3 I think there was just one per feature (ie. 5 or so) where as v. 5.5 has 24 applications. 24! This means that all role configuration and access management is split over 24 applications. To makes matter worse it means there are 24 places to make sure administration privileges and the connectionsAdmin user is configured correctly. This configuration breaking in one Java EE application makes the entire thing come crashing down unless is a JMS or database access credential – then it’s part of WAS. Confused!? Join the club.
Where I do manage feature A or feature B – well ISC is your Swiss army knife – it’s pretty good but was never meant to manage 24 applications running and functioning the concert. That’s the job of a specialized mangement UI which sadly is still missing from the product.
We still lacking a built in way of discovering profiles with problems, file library issues, orphan files, communities with no active owner and the like. Vendors such as Panagenda, Time to Act and Domain Patrol Social does a nice job of plugging the hole but seriously this kind of functionality should be provided by the platform. If a platform is core to any business there should be management tools and a dashboard to gauge the health of the application. No not separate places to check search indexes, seedlists and so on. One place.
Another place where WAS provides strong support but doesn’t really help the overall perception is with security. Security is core to the IBM Connections API’s but since it is delegated to WAS it makes the configuration process cumbersome and hard to troubleshoot. Since access control (authentication and authorization) is delegated from IBM Connections to WAS it’s extremely hard to diagnose since the issue could be in different layers and when there are layers the real cause of the issue might got lost in the reporting chain. Is the user who cannot login due to a WAS issue (login i.e. authentication (usernname/password, SPNEGO, certificates, TAI), roles ie. authorization, directory connectivity) or due to an IBM Connections issue (no user profile matching WAS security name, missing inter-app loginname sync)? Oh and can I trace a login? Well not really as login spans across layers and it could even be different based on which IBM Connections feature I access first. Oh and difference db schemes and ID’s across features makes it even worse.
My head hurts from just thinking about troubleshooting sessions like this.
In IBM Connections API access can be controlled using form based authentication, basic authentication or OAuth (and basically any way security can be managed in WAS e.g. TAI’s). Now from a WAS perspective OAuth is just another supporting technology but for IBM Connections it’s core to its functionality and API’s. Configuration is done using command line wsadmin and requires you to be in a terminal on the Deployment Manager (“the server”). Now there nothing wrong with command line but managing API credentials for an application (IBM Connections) should be part of the app and tied to the app. It should also be possible to provide scoped access to OAuth applications – today it’s all or nothing whereas granting access to just Profiles or Files would make total sense. And to makes matters worse this kind of limitation carry over to the cloud version as the core and API’s are shared.
Security wise we also lack a “root” user with access to all content. Time and time again I hear it as a base requirement for many organizations evaluating IBM Connections. It’s also key to customers and/or ISV’s building custom applications. Without root level access you cannot provide applications that work with application data without requiring a specific user account. Try writing and app that extracts data from or populates communities across the organisation without having a user account specific to that community. Good luck. Only was is to make specific (licensed) user accounts being member of the various communities. And managing username/password/credentials just like any other user. It’s really an issue that should be addressed.
There is definitely room for improvement. Now I didn’t mean for this post to be such a rant but a great platform is being tarnished by really lousy “coherent-ness”. The platform is starting to show its age with all the new features being added and still clearly stinks from originally being disparate apps being glued together. Painting the walls and putting in a new bathroom doesn’t fix the foundation.