Specify different system users for widget life-cycle events

Home

Specify different system users for widget life-cycle events

Specify a system user to manage widget life-cycle events that overrides the default authentication alias created at installation time.

When you install IBM Lotus Connections, the installation wizard automatically creates an authentication alias named connectionsAdmin alias that holds the user ID and password for the system user that is used for every event posting in Lotus Connections. You can override this alias to specify different system users to manage widget life-cycle events for Communities.
Widget life-cycle events are used to notify widget content providers of changes in the community that contains the widget. For example, if a community owner adds the Blog widget to a community, whenever changes are made to the community, widget life-cycle events notify the Blogs application of those changes.
To specify a different system user for widget life-cycle POSTs, first create a J2C authentication alias and then update the widgets-config.xml file to use this new alias. After performing these tasks, you need to map the user in the aliases to the widget-admin role.
To create an J2C authentication alias for Communities...

From the IBM WebSphere Application Server Integrated Solutions Console, select Security > Secure administration, applications, and infrastructure
In the Authentication area, expand Java Authentication and Authorization Service, and click J2C authentication data.
Click New.
Enter an alias name, user ID, and password. For clarity, use an alias name that follows the syntax widget<service name>Alias, where <service name> is the name of the feature for which you want to create the alias.
For example, widgetBlogsAlias.
Click OK.
Repeat steps 1.c- 1.e for each feature for which you want to define a new alias.
Click Save, and then click Save again.
Update the widgets-config.xml file to use the new alias.
Check out the widgets-config.xml file...
CommunitiesConfigService.checkOutWidgetsConfig(“<working_directory>", "cell_name")

where:

<working_directory> is the temporary working directory to which the configuration XML and XSD files are copied. The files are kept in this working while you make changes to them.
cell_name is the name of the WebSphere Application Server cell hosting the Communities feature. This argument is required even in stand-alone deployments.

For example:
CommunitiesConfigService.checkOutWidgetsConfig("C:\\tmp2","JRDESKTOP1Node01Cell")
Navigate to the temporary where you saved the widgets-config.xml file, and open the file in a text editor.
Change the remoteHandlerAuthenticationAlias attribute in the life-cycle element for the widgetDef (widget definition) corresponding to the feature that is to be changed. Be sure to include the full name of the alias, which is likely to include a nodename prefix. For example:
<widgetDef defId="Blog" requires="blogs" modes="view edit search" url="{contextRoot}/blogs/blogsWidget.jsp?version={version}"
                navBarLink="{blogsSvcRef}/{resourceId}" description="blogsDescription" uniqueInstance="true"
                helpLink="{contextRoot}/help/doc/{lang}/community_blog_frame.html">
                <itemSet>
                 <item name="communitiesBaseUrl" value="{communitiesSvcRef}" />
                    <item name="blogsBaseUrl" value="{blogsSvcRef}" />
                    <item name="profilesBaseUrl" value="{profilesSvcRef}" />
                    <item name="atomFeedUrl" value="{blogsSvcRef}/atom/blogs?commUuid={resourceId}" />
     <item name="atomPubUrl" value="{blogsSvcRef}/api/blogs?commUuid={resourceId}" />
     <item name="searchUrl" value="{blogsSvcRef}/atom?search={searchTerm}&amp;commUuid={resourceId}&amp;ps=5&amp;page=0&amp;sortby=0&amp;order=desc&amp;lang=en" />
                </itemSet>
                
                <lifecycle remoteHandlerURL="{blogsInterSvcRef}/roller-ui/BlogsWidgetEventHandler.do" 
                 remoteHandlerAuthenticationAlias="connectionsAdmin">
       <event>remote.app.added</event> 
       <event>remote.app.removed</event> 
       <event>community.visibility.changed</event> 
       <event>community.prepare.delete</event> 
       <event>remote.app.transfer</event>
      </lifecycle>                              
              </widgetDef>
Repeat step 2.c for each feature that has a new alias.
Apply your changes...
Check in the updated widgets-config.xml file...
CommunitiesConfigService.checkInWidgetsConfig(“<working_directory>", "cell_name")

For example:
CommunitiesConfigService.checkInWidgetsConfig("C:\\tmp2","JRDESKTOP1Node01Cell")
To exit wsadmin, type
exit

at the prompt.
Restart the Communities application using the WAS admin console.
Map the user in the alias to the widget-admin role.

From the WAS admin console, select Applications > Enterprise Applications, and select the feature that you want to configure.
Click Security role to user/group mapping in the Detail Properties area.
Locate the widget-admin role in the Role column, and then click Look up users to look up a user or Look up groups to look up a group.
In the Search String field, type the name of the person or group that you want to assign to this role and click Search. If the user or group exists in the LDAP directory, it is returned and displayed in the Available list.
Select the user or group name from the Available list, and then move it into the Selected column by clicking the right arrow.
Repeat steps 3.d and 3.e to add additional people or groups.
Repeat steps 3.c through 3.f to define access levels and assign people to any other aliases that you created.
Click OK.
From the Enterprise Applications > feature > Security role to user/group mapping page, click OK, and then click Save to save the change

Restart all of your WebSphere Application Server instances to make use of the new configuration.
Administer remote applications

Related tasks

Switching to unique administrator IDs for system level communication

+
Search Tips | Advanced Search