Skip to main content link. Accesskey S
  • Log In
  • Help
  • IBM Logo
  • IBM Digital Experience wiki
  • All Wikis
  • All Forums
  • ANNOUNCEMENT: WIKI CHANGE TO READ-ONLY. LEARN MORE...
  • Home
  • Product Documentation
  • Community Articles
  • Learning Center
  • IBM Redbooks
  • API Documentation
Search
Community Articles > Resources for WebSphere Portal administrators and developers > Configuring ‘Single Sign On’ between Web Sphere Portal Server 7.0, Tivoli Access Manager WebSEAL version 6.1 on AIX 6.1
  • New Article
  • Share Show Menu▼
  • Subscribe Show Menu▼

About the Original Author

Click to view profileIBM contributorAshutosh Rajput
Contribution Summary:
  • Articles authored: 1
  • Articles edited: 0
  • Comments Posted: 0

Recent articles by this author

Configuring ‘Single Sign On’ between Web Sphere Portal Server 7.0, Tivoli Access Manager WebSEAL version 6.1 on AIX 6.1

Overview Single signon (SSO) is a mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single signon reduces human error, a major ...
Community articleConfiguring ‘Single Sign On’ between Web Sphere Portal Server 7.0, Tivoli Access Manager WebSEAL version 6.1 on AIX 6.1
Added by IBM contributorAshutosh Rajput | Edited by IBM contributorDavid A Batres on December 22, 2014 | Version 5
  • Edit
  • More Actions Show Menu▼
Rate this article 1 starsRate this article 2 starsRate this article 3 starsRate this article 4 starsRate this article 5 stars
expanded Abstract
collapsed Abstract
No abstract provided.
ShowTable of Contents
HideTable of Contents
  • 1 Overview
  • 2 Brief Description of the products used
  • 3 Request Flow
    • 3.1 Configuring Trust Association Interceptor (ETAI)
      • 3.1.1 Installing the package in IBM WebSphere Application Server
      • 3.1.2 Configuring IBM WebSphere Application Server
      • 3.1.3 Enable trust association
      • 3.1.4 Add custom properties
    • 3.2 Configuring Tivoli Access Manager WebSEAL
      • 3.2.1 Required junction parameters
      • 3.2.2 Create a trusted SSO user
      • 3.2.3 Set the dummy password
    • 3.3 Enabling Global Security
    • 3.4 Updating properties files
      • 3.4.1 wkplc.properties
      • 3.4.2 wkplc_comp.properties
      • 3.4.3 wp_security_ids.properties
    • 3.5 Executing scripts
      • 3.5.1 WebSphere Portal to TAM connection
      • 3.5.2 WebSphere Portal to LDAP connection
  • 4 Appendices
    • 4.1 A. References
    • 4.2 B. Dfinitions
    • 4.3 C. Creating User and junction in TAM
  • 5 About the author

Overview


Single sign-on (SSO) is a mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable.

This document describes how to enable SSO on WebSphere Portal Server using Tivoli Access Manager – WebSEAL in an AIX environment. the following describe how to accomplish this task.
1. Configuring and enabling Trust Association Interceptor (ETAI)
2. Configuring Tivoli Access Manager WebSEAL
3. Enabling Global Security in the WebSphere Portal Server
4. Updating properties files – For WebSphere Portal Server, which will be used by the scripts
5. Executing scripts for connecting WebSphere Portal Server to Tivoli access Manager –WebSEAL and LDAP

Brief Description of the products used




Tivoli Access Manager Java runtime environment offers a reliable environment for developing and deploying Java applications in a Tivoli Access Manager secure domain.


Tivoli Access Manager Runtime contains runtime libraries and supporting files that applications can use to access Tivoli Access Manager Servers.


Access Manager Application Development Kit provides a development environment that enables you to code third-party applications to query the authorization server for authorization decisions.


Access Manager Authorization Server The Access Manager Authorization Server provides access to the authorization service for third-party applications that use the Tivoli Access Manager authorization API in remote cache mode. The authorization server also acts as a logging and auditing collection server to store records of server activity.


WebSEAL is a high-performance, multi-threaded Web server that applies fine-grained security policy to the Tivoli Access Manager protected Web object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy. WebSEAL normally acts as a reverse Web proxy by receiving HTTP/HTTPS requests from a Web browser and delivering content from its own Web server or from junctioned back-end Web server /application servers. Requests passing through WebSEAL are evaluated by the Tivoli Access Manager Authorization service to determine whether the user is authorized to access the requested resource.


  • WAS plug-in is WebSphere Application Server Web server plug-in, which forwards HTTP requests from the Web server to a WebSphere application.

  • IBM HTTP Server is a web server

  • WebSphere Application Server is the application server

  • WebSphere Portal Server is the application server

  • Trust Association Interceptor (TAI) provides a way for users to become known to WebSphere Application Server without having to re-authenticate. The result is a simpler, yet still secure, authentication process for requests flowing throughout the network.


Request Flow



  1. The user presents authentication information to WebSEAL during a request for a resource in the protected object space.
    1. WebSEAL invokes the configured authentication module for that type of authentication information.
    2. The authentication module validates the authentication information and returns an identity to WebSEAL.
    3. WebSEAL uses this identity to create a credential for that user, based on data stored for that user in the user registry. This credential is used during authorization decisions for requests made by this user.
  2. An authenticated client request for a resource is directed to the resource manager server and intercepted by the policy enforcer process. For example, the resource manager can be WebSEAL for Hypertext
  3. Transfer Protocol (HTTP), HTTPS access or another application.
  4. The policy enforcer process uses the authorization API to call the authorization service for an authorization decision.
  5. The authorization service performs an authorization check on the resource.
  6. The decision to accept or deny the request is returned as a recommendation to the resource manager (through the policy enforcer).
  7. If the request is finally approved, the resource manager passes the request on to the application responsible for the resource in this case the WebSphere Portal Server page.
  8. The request is than pass to TAI ++ and which validates it and returns the user identity as either a distinguished name (DN) or a short name. WebSphere Application Server performs a registry lookup to verify the distinguished name or convert the short name to a distinguished name before searching for group memberships for that user. If the registry lookup fails, WebSphereWebSphere Application Server refuses to trust the user. If the registry lookup succeeds, WebSphere Application Server generates a Lightweight Third-Party Authentication (LTPA) token for the user. It stores it as a cookie for subsequent authentication during the user's session.
  9. WebSphere Portal server interacts with its database for other security information.

Configuring Trust Association Interceptor (ETAI)


Installing the package in IBM WebSphere Application Server



The ETAI is packaged in this JAR file: com.ibm.sec.authn.tai.ETAI_6.0.jar
  1. Copy the JAR file into the plugins directory from the installation package.

  2. Run the WAS_HOME/bin/osgiCfgInit script to configure the new oSGI bundle.

  3. Copy the jar file to was_home/lib/ext.
  4. Ensure that the ETAI is installed on all of the IBM WebSphere Application Server instances in the cell.

Configuring IBM WebSphere Application Server



Enable global IBM WebSphere Application Server application security.
  • Refer to section 2.3 for enabling WebSphere Application Server Global security.

Route requests through a web server.
  • To route the request through Web server IBM HTTP server needs to be installed with the plug-in for the Web server.
  • Refer to the WebSphere Portal Server installation document for installing and configuring IBM HTTP Server plug-in


Enable trust association


  1. Log in to WebSphere Portal Server Console using the administrator ID.
  2. Expand Security and select Global Security as shown in figure 1.

    Figure 1

  3. Expand Web and SIP security as shown in figure 2.

    Figure 2

  4. Click on Trust Association as shown in figure 3.

    Figure 3



  5. Select Enable Trust Association check box, Click Interceptors as shown in figure 4.

    Figure 4


  6. Click New as shown in figure 5.

    Figure 5


  7. Enter com.ibm.sec.authn.tai.TAMETai into the Interceptor class name field in figure 6. Click Apply, and Click Save to apply the configuration changes.
    Figure 6



Add custom properties



This section follows on from the configuration steps in the preceding section.
  1. Browse to Security, then select Global Security > Trust Association >Interceptor.

  2. Click on the class name link (created in the previous section) as shown in figure 7.

    Figure 7




  3. Enter the entries as mentioned in figure8 and click OK, Click Save on next screen to apply the changes as shown in figure 8.

    Figure 8




  4. The value of ‘userid’ should be the user created in the section 1.2 (create a trusted SSO user).

  5. Restart the Tivoli Integrated Portal server after all of the custom properties above are saved.


Note: The application server generates and sets an LTPAToken cookie for all successfully authenticated resource requests, regardless of whether the request is for protected or unprotected web resources. This is the default behavior in WAS 7.0 and can be configured using a custom security property - com.ibm.websphere.security.web.setLTPATokenCookieToUnprotectedURI. For more details, refer to the following link from the knowledge center:

http://www-01.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.doc/info/ae/ae/usec_seccustomprop.html?cp=SSAW57_7.0.0%2F1-16-5-866




Configuring Tivoli Access Manager WebSEAL



For the Extended Trust Association Interceptor to accept requests from WebSEAL, you need to do the following tasks on the WebSEAL server to ensure that an Extended Trust Association Interceptor targeted HTTP request is sent.
  1. Create the junction with the required parameters.
  2. Create a trusted SSO user.
  3. Set the dummy password in the configuration file.

Required junction parameters


There are many parameters available when creating a junction in WebSEAL. The two that are required by the Extended Trust Association Interceptor are:

–b supply
It ensures that WebSEAL passes the BA header in the HTTP request. The Extended Trust Association Interceptor requires the dummy password in the BA header; the username is not used.

–c iv-creds
It ensures that WebSEAL passes the logged in user's credential in an iv-creds header in the HTTP request. The Extended Trust Association Interceptor requires this header or it will not handle the request. Other headers can also be passed, such as iv-user, but the iv-creds header must also be passed.

The following example shows how to create a junction in WebSEAL 6.1

Syntax -
server task "webseal_instance_name" create -b supply -c iv-creds -t tcp -h "websphere_hostname" -p "websphere_app_port_number" "junction_name"

Example-
server task default-webseald- create -b supply -c iv-creds -t tcp -h -p 80 /poc2portal

Create a trusted SSO user


The Extended Trust Association Interceptor requires a user to exist in the user registry that will be used to authenticate trust. This user and their password will become the central part of establishing trust between WebSEAL and WebSphere Application Server. The value of the custom property com.ibm.websphere.security.webseal.loginId will be set to this user, and the dummy password in WebSEAL will be set to this user's password.

Syntax-
user create sso cn=sso,o=ibm,c=au sso sso ssopwd
user modify ssouser account-valid yes

If the custom property com.ibm.websphere.security.webseal.useWebSphereUserRegistry is set to true, this user must be created in the WebSphere Application Server user registry. (See the WebSphere Application Server Info Center for details.)

Set the dummy password


WebSEAL provides a mechanism for predetermining the password that's passed in the basic authentication header of the HTTP request. Set the dummy password in the WebSEAL instance configuration file using the –b supply parameter described inRequired junction parameters. The configuration file to update, webseald-instancename.conf, is in your webseal_home/etc directory.
  1. Browse to /opt/pdweb/etc and open the file webseald-default.conf, search for basicauth-dummy-passwd, and change the value of this property to the password of the trusted SSO user. Save the file and restart your WebSEAL instance so the new property value will take effect.

  2. Create an ACL:

    Syntax-

    acl create adminACL
    acl modify adminACL set group SecurityGroup Tr


  3. Attach ACL:
    Syntax-
    acl attach /WebSEAL/-default/poc2portal/wps/portal adminACL



Enabling Global Security




  1. Log in to WebSphere Portal Server Console using the administrator id.

  2. Expand Security and select Global Security as shown in figure 9.

    Figure 9


    Click on “Security Configuration Wizard” as shown in figure 10.

    Figure 10



  3. Select enable application security and click Next as shown in figure 11.

    Figure 11




  4. Select Standalone registry and click Next as shown in figure 12.

    Figure 12




  5. Fill in the below details and Click Next as shown in Figure 13.

    Figure 13


  6. Where is the user id with admin access in the user registry to which you are connecting.

  7. Click finish.

    Figure 14




  8. Click Save to apply changes to the master configuration and restart the WebSphere Application Server as shown in figure 15.

    Figure 15






Updating properties files




wkplc.properties




This property file needs to be updated for WebSphere Application Server, WebSphere Portal Server and LDAP related information required by the scripts mentioned in the next section.


Here are the properties updated:



EngineInstallLocation=<path to ConfigEngine directory>


WasSoapPort=<SOAP port>


WasRemoteHostName=<fully qualified host name>


VirtualHostName=default_host


WasUserid=cn=userId,dc=xyz,dc=com


WasPassword=<password>


WasHome=/usr/IBM/WebSphere/AppServer <AppServer directory path>


WasUserHome=/usr/IBM/WebSphere/wp_profile <wps profile path>


ProfileName=wp_profile <profile_name>


CellName=<cell name>


NodeName=<node name>


ServerName=WebSphere_Portal


WasAdminServer=server1


wasJvmBitType=x64 (specific to AIX 64)


WpsInstallLocation=/usr/IBM/WebSphere/PortalServer <wps installation path>


WpsHostName=<fully qualified host name>


WpsHostPort=


PortalAdminId=cn=userId,dc=xyz,dc=com


PortalAdminPwd=<password>


PortalAdminGroupId=cn=admingroup,dc=xyz,dc=com


standalone.ldap.id=ldapitds <create an id>



standalone.ldap.host=<ldap host name>


standalone.ldap.port=<ldap instance listening port>


standalone.ldap.bindDN=cn=root


standalone.ldap.bindPassword=<bind password>


standalone.ldap.ldapServerType=IDS <If registry is Tivoli Directory Server>


standalone.ldap.userIdMap=*:uid


standalone.ldap.groupIdMap=*:cn


standalone.ldap.groupMemberIdMap=ibm-allGroups:member;ibm-allGroups:uniqueMember


standalone.ldap.userFilter=(&(uid=%v)(objectclass=ePerson))


standalone.ldap.groupFilter=(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=groupOfURLs)))


standalone.ldap.serverId=cn=userId,dc=xyz,dc=com


standalone.ldap.serverPassword=<password>


standalone.ldap.primaryAdminId=cn=userId,dc=xyz,dc=com


standalone.ldap.primaryAdminPassword=<password>


standalone.ldap.primaryPortalAdminId=cn=userId,dc=xyz,dc=com


standalone.ldap.primaryPortalAdminPassword=<password>


standalone.ldap.primaryPortalAdminGroup=cn=admingroup,dc=xyz,dc=com


standalone.ldap.baseDN=dc=xyz,dc=com



If you want to change the admin user need to specify these properties:


newAdminId=cn=userId,dc=xyz,dc=com


newAdminPw=<password>


newAdminGroupId=cn=admingroup,dc=xyz,dc=com



wkplc_comp.properties


This property file needs to be updated for Tivoli Access Manager (TAM) related information required by the scripts mentioned in the next section. The properties that need to be updated are as follows. For complete list of properties and there explanation refer to the attached property file:



wp.ac.impl.PDAdminId=<TAM admin user ID>


wp.ac.impl.PDAdminPwd=<TAM admin password>


wp.ac.impl.PDPermPath=${WasHome}/java/jre/PdPerm.properties


wp.ac.impl.PDClasspath=${WasHome}/java/jre/lib/ext/PD.jar


wp.ac.impl.PDHome=${WasHome}/java/jre/PolicyDirector


wp.ac.impl.JavaHome=${WasHome}/java/jre/


wp.ac.impl.CfgFilesPath=${WasHome}/java/jre


wp.ac.impl.TamHost=<fully qualified hostname of TAM>


wp.ac.impl.PDServerName=amwp70 (you can specify instance name you want to create as TAM server instance)


wp.ac.impl.SvrSslCfgPort=7223


wp.ac.impl.SvrSslCfgMode=remote


wp.ac.impl.PDPolicyServerList=<fully qualified hostname> :7135:1


wp.ac.impl.PDAuthzServerList= fully qualified hostname:7136:1


wp.ac.impl.PDKeyPath=${WasHome}/java/jre/lib/pdperm.ks



You can specify the below mentioned properties if you need the scripts to create the junction or you can create through command. Refer to Appendix Section C for the command details:


wp.ac.impl.JunctionType=tcp


wp.ac.impl.JunctionPoint=/wpsv70 <Junction with this name will be created>


wp.ac.impl.WebSealInstance=<web seal instance name>


wp.ac.impl.TAICreds=iv-user,iv-creds


wp.ac.impl.JunctionHost=< fully qualified hostname for junction>


wp.ac.impl.JunctionPort =80


Tivoli Access Manager: WebSphere Application Server WebSEAL TAI parameters. You can specify these parameters and the script will enable TAI and create these custom properties with the values specified. Script installs and configures TAI ++.


So if you want to use ETAI for trust association you can leave these parameters blank and refer to section 2.1. If you want to use TAI++ skip section 2.1 and enter the values to the parameters mentioned below and the script (enable-tam-all) will enable the trust association and will create all the parameters.


wp.ac.impl.loginId=<SSO user id>


wp.ac.impl.BaUserName=<admin id>


wp.ac.impl.BaPassword=<admin password>


wp.ac.impl.checkViaHeader=false


wp.ac.impl.viaDepth=0


wp.ac.impl.ssoPwdExpiry=600


wp.ac.impl.ignoreProxy=false





Tivoli Access Manager: Portal authorization parameters .The following information is used to authenticate with TAM:

wp.ac.impl.PDRoot=/WebSEAL


wp.ac.impl.PDCreateAcl=true





wp_security_ids.properties


These properties are used by wp-modify-ldap-security and wp-update-standalone-ldap scripts to change the registry from WebSphere Application user registry to LDAP Stand alone user registry.



standalone.ldap.id=ldapitds <this will create an id with the name you provide here>


standalone.ldap.host= <fully qualified ldap hostname>


standalone.ldap.port=<ldap instance port>


standalone.ldap.bindDN=cn=root


standalone.ldap.bindPassword=<password>


standalone.ldap.ldapServerType=IDS


standalone.ldap.userIdMap=*:uid


standalone.ldap.groupIdMap=*:cn


standalone.ldap.groupMemberIdMap=ibm-allGroups:member;ibm-allGroups:uniqueMember


standalone.ldap.userFilter=(&(uid=%v)(objectclass=ePerson))


standalone.ldap.groupFilter=(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=groupOfURLs)))


standalone.ldap.serverId=cn=userId,dc=xyz,dc=com


standalone.ldap.serverPassword=<password>


standalone.ldap.primaryAdminId=cn=userId,dc=xyz,dc=com


standalone.ldap.primaryAdminPassword=<password>


standalone.ldap.primaryPortalAdminId=cn=userId,dc=xyz,dc=com


standalone.ldap.primaryPortalAdminPassword=<password>


standalone.ldap.primaryPortalAdminGroup=cn=admingroup,dc=xyz,dc=com


standalone.ldap.baseDN=dc=xyz,dc=com


standalone.ldap.personAccountRdnProperties=uid


standalone.ldap.groupRdnProperties=cn



Executing scripts




WebSphere Portal to TAM connection





Configuring and connecting WebSphere Portal Server is 3 step processes. These steps should be executed in the sequence, proceed to next step only after you get the ‘Build Successful” message in the command prompt after each step.

Step 1: Run the following task to create the AMJRTE properties file:


.


/ConfigEngine.sh run-svrssl-config -DWasUserid= <was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>




Note: If the configuration task fails, validate the values in the wkplc_comp.properties file.
After successful completion of the task following file will be created:
AppServer_root/java/jre/PolicyDirector/PdPerm.properties


Step 2: Run the following task to validate that the AMJRTE properties exists which was created in the previous step:


./ConfigEngine.sh validate-pdadmin-connection -DWasUserid= <was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>



Note: If the task does not run successfully. Run the run-svrssl-config task to create the properties file, and then run the validate-pdadmin-connection task again. If it fails again verify the values in wkplc.properties. The fact that the task does not run successfully indicates that your portal cannot connect to the Tivoli Access Manager server.


Step 3: Run the following validation task: This task will take 10 to 15 minutes for the completion and it will create all the junctions, ACL, TAI ++ custom properties:

./ConfigEngine.sh enable-tam-all -DWasUserid= <was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>

Note: If the task does not run successfully, ensure the values you specified in wkplc_comp.properties are valid.

WebSphere Portal to LDAP connection

WebSphere Portal is configured with the default federated repository with a built-in file repository. Therefore, you must run the wp-modify-ldap-security task to switch to a standalone LDAP user registry.

Run the following task:


./ConfigEngine.sh wp-modify-ldap-security -DWasUserid=<was admin userid> -DWasPassword=<admin password> -Dwp.ac.impl.PDAdminPwd=<Pdadmin password>






Appendices


A. References



Release Notes for ITAM 6.1:
http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame.doc/am611_relnotes.htm

ITAM 6.1 installation guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame.doc/am611_install.pdf

IBM HTTP Server installation guide:
ftp://public.dhe.ibm.com/software/webserver/appserv/library/v70/ihs_70.pdf

For windows installation refer the following link:
http://www.ibm.com/developerworks/tivoli/library/t-ssotam/

B. Dfinitions



AMRT
Access Manager Run Time
AMRTJ
Access Manager Runtime or Java
AMWPM
Access Manager Web Portal Manger
TDS Client
Tivoli Directory Server Client
AMADK
Access Manager Development Kit
ITIM
IBM Tivoli Identity Manager
ITAM
IBM Tivoli Access Manager
WAS
WebSphere Application Server

C. Creating User and junction in TAM


Run the command ‘pdadmin’

pdadmin> Login
Enter ser ID: userID
Enter Password:
Pdadmin UserID>

Run the following commands to create groups, users, ACL and junctions:

1. Creating groups:
group create group1 cn=group1 ,dc=xyz,dc=com group1

2. Creating Users:
user create user1 cn=user1,dc=xyz,dc=com user1 user1 user1234 group1

3. Creating ACL:
acl create group1ACL
acl modify group1ACL set group group1 Tr

4. Creating junction:
server task <webseal instance name> create -t tcp -c iv_user -h <target host name> -p 80 /<junction_name>


Name of the object to be attached to the acl is derived by commands as shown below in the padmin:


pdadmin userID> object list
/Management
/WebSEAL
pdadmin userID> object list /WebSEAL
/WebSEAL/<hostname>-default

5. Attaching ACL:

acl attach /WebSEAL/<hostname>-default/junction_name/context root group1ACL

About the author


Ashutosh Rajput
I am currently working as Technical lead with IBM and has 9 years of experience in Java/J2EE technologies including Rational, WebSphere and Tivoli Products
I hold Master of Computer Application (MCA) degree and I am Sun certified Java Programmer (SCJP), Sun Certified Web Component Developer (SCWCD), and Sun Certified Business Component Developer (SCBCD).

  • Edit
  • More Actions Show Menu▼


expanded Attachments (0)
collapsed Attachments (0)
Edit the article to add or modify attachments.
expanded Versions (5)
collapsed Versions (5)
Version Comparison     
VersionDateChanged by              Summary of changes
This version (5)Dec 22, 2014, 8:56:41 PMDavid A Batres  IBM contributor
3Apr 24, 2013, 2:54:24 PMAmanda J Bauman  IBM contributor
3Dec 22, 2014, 8:46:42 PMDavid A Batres  IBM contributor
1Apr 24, 2013, 2:06:32 PMAmanda J Bauman  IBM contributor
1Apr 24, 2013, 2:34:40 PMAmanda J Bauman  IBM contributor
expanded Comments (0)
collapsed Comments (0)
Copy and paste this wiki markup to link to this article from another article in this wiki.
Go ElsewhereStay ConnectedHelpAbout
  • IBM Collaboration Solutions wikis
  • IBM developerWorks
  • IBM Software support
  • Twitter LinkIBMSocialBizUX on Twitter
  • FacebookIBMSocialBizUX on Facebook
  • ForumsLotus product forums
  • BlogsIBM Social Business UX blog
  • Community LinkThe Social Lounge
  • Wiki Help
  • Forgot user name/password
  • About the wiki
  • About IBM
  • Privacy
  • Accessibility
  • IBM Terms of use
  • Wiki terms of use