+

Search Tips   |   Advanced Search

Configure single sign-on for portlets with TAM and SPNEGO

Single sign-on (SSO) enables users to log in to a Connections application, and switch to other applications within the product without having to authenticate again.

This procedure describes an approach that uses the Kerberos authentication protocol. This authentication method allows Tivoli Access Manager and users web browsers to prove their identities to one another in a secure manner. After users sign in to their Active Directory Windows client systems, they are automatically signed into both Tivoli Access Manager and Connections.

Configuring IBM Connections and WebSphere Portal to share a single Deployment manager saves on administration time by combining administration tasks for the two applications. Establishing a single-sign on environment benefits the users by creating a more seamless environment between the two applications.

Follow these steps to configure single sign-on.

  1. Before federating Portal as a managed node of the Connections dmgr, verify the realms match between Connections dmgr and Portal.

    If change the realm names so they match, follow the steps in Change the realm name.

  2. To collect files from the primary node and copy them to the dmgr:

    1. From the primary node...

        cd wp_profile_root/ConfigEngine
        ConfigEngine.bat collect-files-for-dmgr -DWasPassword=foo

      This task creates a compressed file containing all the files which must be copied to the dmgr. The compressed file, named filesForDmgr.zip, is placed in...

        wp_profile_root/filesForDmgr

    2. Stop the dmgr.

    3. Expand each of the files in the filesForDmgr.zip file into the correct location on the dmgr based on the directory names within the compressed file. The directory names in the compressed file are based on the typical default directory names. The directory...

        AppServer/profiles/Dmgr01

      ...is used to identify the dmgr profile root, and the AppServer directory is used to identify the dmgr installation root directory. If the dmgr was installed into the default directory (AppServer) and the profile was created in the default directory...

        AppServer/profiles/Dmgr01

      ...then the compressed file can be expanded directly into the directory above the AppServer directory; for example /IBM/WebSphere.

    4. Start the dmgr.

  3. To augment a dmgr profile,

      cd AppServer_root/bin
      manageprofiles.bat -augment -templatePath c:/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment -profileName Dmgr01

  4. Restart the dmgr.

  5. Add the same Portal administration group as an administrators group on the Connections dmgr.

  6. Federate the primary node: 
    cd wp_profile_rootbin 
addNode.bat dmgr_hostname dmgr_port \
            -includeapps \
            -includebuses \
            -username was_admin_user 
            -password was_admin_password

    For example: 

    addNode.bat DMhost.cn.ibm.com 8879 \
            -includeapps \
            -includebuses \
            -username adminuser \
            -password adminpwd

  7. On the Portal server, run syncNode.bat and then restart the dmgr and all node agents.

  8. To configure the IBM HTTP Server with Single Sign-On, delete and re-add the web server on the WAS console in order to remap all applications, including Portal, and import the Portal certificate into IBM HTTP Server.

  9. Skip this step if we are deploying on Portal 8. To Configure the same SPNEGO single sign-on for Portal and Connections:

    1. Create user for Portal host server on AD

    2. Create keytab file for Portal server on AD： 
      ktpass -out path_to_keytab –princ SPN 
-mapuser account_name -mapOp set –pass account_password
      Where:

      • path_to_keytab is the file path to store the generated keytab file.

      • SPN is the Kerberos service principal name.

      • account_name is the service account name.

      • account_password is the password associated with the service account.

      For example:

        ktpass -princ HTTP/portal.cn.ibm.com@cn.ibm.com -out c:\portal.keytab -mapuser portaluser -mapOp set -pass Passw0rd

    3. Merge the portal keytab into the merged Connections keytab by running the ktab command with the following switch:

        -m source_keytab_name destination_keytab_name

      Where:

      • source_keytab_name is the name of the keytab file on the source system.

      • destination_keytab_name is the name of the keytab file on the destination system.

      For example:

        c:\IBM\WebSphere\AppServer\java\jre\bin>ktab.exe -m y:\SPNEGO\portal.keytab y:\SPNEGO\merged.keytab

    4. Recreate the krb5.conf file with the new merged keytab file: 
      $AdminTask createKrbConfigFile

{

-krbPath appserver\java\jre\lib\security\krb5.conf

-realm REALM 
-kdcHost kdc_hostname 
-dns dns_hostname 
-keytabPath path_to_keytab }
      For example: 
      wsadmin.bat -user adminuser -password adminpwd $AdminTask createKrbConfigFile {-krbPath y:\SPNEGO\krb5.conf -realm CN.IBM.COM -kdcHost AD.cn.ibm.com -dns cn.ibm.com -keytabPath y:\SPNEGO\merged.keytab}

    5. Enable SPNEGO single sign-on by configuring Kerberos in the WAS console, following the steps in the Enable single sign-on for Tivoli Access Manager with SPNEGO topic.

    6. Synchronize the node and restart the dmgr node. If we cannot manage the Portal node on the WAS console, manually synchronize the node and restart the dmgr node.

  10. Configure Tivoli Access Manager on the Portal server, following the directions in the Configure Tivoli Access Manager article that corresponds to the Portal server: in the WebSphere Portal Knowledge Center.

    For the connections integration with the portlets, it is important that WebSEAL session cookies are sent to the junction server. This can be defined by adding the -k option to the commands that create a junction. For example, on Portal 7: 

    server task default-webseald-TAMhost.cn.ibm.com create -t ssl -b filter -A -F C:\WASLTPA.key -Z password 
-h DMhost.cn.ibm.com -c all -f -k -j -J trailer /wpsv70

ConfigEngine.bat run-svrssl-config -Dwp.ac.impl.PDAdminPwd=foo ConfigEngine.bat validate-pdadmin-connection -DWasPassword=foo -Dwp.ac.impl.PDAdminPwd=foo ConfigEngine.bat enable-tam-all -DWasPassword=foo

  11. Configure the ACL for WebSEAL to allow HTTP PUT requests, add an ACL to the Portal Junction.

    1. Create a default IBM Connections ACL to override the default WebSEAL ACL by ... 
      acl create lc3-default-acl 
acl modify lc3-default-acl set user sec_master TcmdbsvaBRlrx acl modify lc3-default-acl set any-other Tmdrx acl modify lc3-default-acl set unauthenticated T
acl modify lc3-default-acl set group iv-admin TcmdbsvaBRrxl acl modify lc3-default-acl set group webseal-servers Tgmdbsrxl

    2. Attach the default ACL to application root URLs:

        acl attach /WebSEAL/tam_server-WebSEAL_instance/app_root lc3-default-acl

      where:

      • tam_server is the host name of the Tivoli Access Manager server

      • WebSEAL_instance is the name of the instance of the WebSEAL server configured to manage IBM Connections. For example: default

      • app_root is the root path to the Connections applications, including the following: /activities, /blogs, /cognos, /communities, /dogear, /files, /forums, /homepage, /news, /metrics, /mobile, /moderation, /profiles, /search, and /wikis

      • lc3-default-acl is the access control list (ACL) definedd. For example: acl attach /WebSEAL/tam.myco.com-default/activities example-default-acl. In this case, the command is: acl attach /WebSEAL/tam.myco.com-default/PORTAL_VHOST_JCT example-default-acl.


Parent topic:
Configure authentication for the portlets