IBM Connections Extension license – how to handle varying user entitlement and which drawbacks I see

As I blogged the other day (IBM Connections Extension license) IBM has released an extension license for IBM Connections to allow customers to buy the remaining features (besides Profiles and Files). It did however beg the question: “So how do I control access to the remaining features for users not entitled to use all features in Connections?”. After asking Ed Brill the solution from the IBM Connections team is surprisingly simple and easy to implement. It does however put the burden on you as the administrator is it’s not a “checkbox solution”. Let me try and explain how to do it.

In IBM Connections (and all other J2EE applications) access to functionality is controlled by roles. That is the container will verify that a user has been mapped to a particular role (either as the user or by virtue of being member of a group) before granting access. In Websphere Application Server this is done in the Integrated Solutions Console (ISC) on a per application basis. The way you restrict access to particular features is the same way you force users to log into Connections and is nicely described in the wiki/InfoCenter. The way you would do it for this scenario is to create an LDAP group of fully entitled users and make sure only these users are granted access to features other than Profiles and Files.

The solution works and is easy to implement but is has a major drawback in it doesn’t change the main menus. At least to the best of my knowledge as the service that returns menu items reads of the general Connections configuration and does not take the access of a particular user into account. A better solution would of course be that the service was aware of the access restriction and only features to which a user has access are presented in the menus. It would also lend itself better to a simpler UI for these casual users of Connections.

Another issue is that the approach doesn’t restrict a fully entitled user (“user 1”) to share information with a limited entitled user (“user 2”) in say communities. “User 1” is free to add “user 2” but “user 2” would be unable to see the information. The user would receive e-mail notifications etc. but wouldn’t be able to open the community. The user would try and go to the community, could log in successfully but still be unable to access the the community. Probably unable to realize why. The main culprit here is that the name resolution service isn’t aware of the – potentially – limitied entitlement of some users. I see helpdesk calls on the horizon.

So while I really, really, really praise IBM for the Profiles/Files entitlement being added to Notes 8.5.3 I also see room for improvement. The role based approach allows you to manage access and thus avoid problems in the event of an IBM compliance check but there are user experience issues. Hopefully IBM will address these in upcoming released.

4 thoughts on “IBM Connections Extension license – how to handle varying user entitlement and which drawbacks I see”

  1. In theory, this would work for Sametime as well, but in reality, it doesn’t, because the entitled user can still invite Entry-users to meetings, and the meeting room will open, but never connect for the Entry user, and never display any error message either.

    Lots of room for improvement there! :-/

    Like

  4. I haven’t tried this myself so I beg your pardon for this.

    I refer to your last example, the one of Communities and "user 1" and "user 2".

    I GUESS that, by default, if the community is not PRIVATE, then "user 2" would be able to READ the content of the community regardles of the fact that he has the right to WRITE into it. SO, "user 2" would not be able to accept the invitation from "user 1" nor he will be able to "ask to join" a community, but he may be able to browser it AT LEAST as ANONYMOUS

    Of course, unless ANONYMOUS is also removed access to everything else, I guess. 

    Like

Comments are closed.