JazzSM DASH - Console Integration (SSO) problems between DASH and Predictive Insights (PI)

Body

When installing PI on the DASH host, the installation scripts should automatically configure SSO between DASH and PI for support of the PI console integration in DASH (the snowflake).  If you don't see the snowflake icon for the PI console integration, it likely means SSO between DASH and PI is not configured correctly. 

Here are the requirements for the console integration between DASH and PI to work:

1) You must use the fully qualified domain name (FQDN) in the DASH login URL
2) If the user is NOT in one of the following groups in the user repository, then access will need to be added either for the user or for an appropriate group that the user is in.

3) The user repository must be common to both DASH and PI (usually LDAP).
4) SSO must be enabled on both DASH and PI.
5) Both DASH and PI must share the same ltpa keys

Here are some tips for examining items 3-5 above:

To ensure the user repository (typically LDAP) is the same for both DASH and PI, examine the following files:
For LDAP, on the DASH server look at the [JazzSM Home]/profile/config/cells/JazzSMNode01Cell/wim/config/wimconfig.xml
Check the value specified for the following two properties for the LDAP configuration:
<config:connections host=
<config:participatingBaseEntries name=

In the PI installation look for the [PI UI Home]/wlp/usr/shared/config/ldapRegistry.xml file.
In that file check the ldap connection information and ensure it matches the DASH configuration.
Also, make sure all steps in the following PI documentation are followed to ensure LDAP is enabeled:
https://www.ibm.com/support/knowledgecenter/en/SSJQQ3_1.3.6/com.ibm.scapi.doc/admin_guide/t_oapi_adminguide_configureuserregistry.html

Make sure the same credentials work in DASH and in PI by logging into each application.  
For DASH:
https://[DASH FQDN]:16311/ibm/console

For PI:
https://[PI FQDN]:9998/predictiveinsights/jsp/wlp/wlpAnomalySearch.jsp

To ensure SSO is configured on DASH and PI, do the following:
On DASH, examine the [JazzSM Home]/profile/config/cells/JazzSMNode01Cell/security.xml file.
Look for the following entry:
<singleSignon xmi:id="SingleSignon_1" requiresSSL="true" domainName=".ibm.com" enabled="true"/>
Ensure "enabled="true", and the domain value is set.

In the PI install, examine the [PI UI Home]/wlp/usr/servers/piserver/ssoConfig.xml file.
Ensure the domain is set and matches the domain specified in the DASH SSO configuration.

Ensure DASH and PI share the ltpa keys. 
This can be tricky, so it may be easier to simply generated a new ltpa keys file on DASH and configure PI to use the new file.  To do that:
1) Log into DASH and navigate to Security > Global Security > LTPA.
2) Enter a password you want to use for the key file.  
3) Enter a file name ("ltpa.keys") path where the key file will be generated.  For example: /tmp/ltpa.keys
4) Click "Export keys"

5) Stop the PI UI process.
6) In the PI installation, make a backup of the existing ltpa.keys file under: [PI UI home]/wlp/usr/servers/piserver/resources/security/
   For example, make a copy called ../ltpa.keys.back.   Move the original file out of the security directory.
7) Copy the ltpa.keys file you exported from DASH in step 4 to:  [PI UI home]/wlp/usr/servers/piserver/resources/security/
8) Execute the [PI UI Home]/wlp/bin/securityUtility to encrypt the ltpa key file password string.  For example:
      [PI UI Home]/wlp/bin/securityUtility encode [ltpa key file password string]
   Replace "[ltpa key file password string]" with the password you specified in step 2.
9) Make a backup of the [PI UI Home]/wlp/usr/servers/piserver/ssoConfig.xml file and then update the original with the new encrypted password string.  
10 Start PI.  Both DASH and PI should now have common ltpa keys.

Testing Single sign-on
In order for the snowflake to show up in DASH SSO must work. It's a good idea to test SSO outside of the console integration.  To do that:

1) Log into DASH using the fully qualified domain name in the login URL.  For example: https://[DASH FQDN]:16311/ibm/console
2) Open another browser tab and then load a PI client URL.  For example:  https://[PI FQDN]:9998/predictiveinsights/jsp/wlp/wlpAnomalySearch.jsp

Enabling SSO traces:
If SSO is working, you should not get a login prompt when loading the PI URL in the new browser tab.

If you have confirmed all of the above and SSO is still not working, enabled WebSphere security traces in PI and then retry the above SSO test.  To enable security traces in PI:
From the PI server:

Add the following line to the second to last line of the [PI UI Home]/wlp/usr/servers/piserver/server.xml file:

<logging traceSpecification="*=info:com.ibm.ws.security.*=all:com.ibm.websphere.security.*=all:com.ibm.websphere.wim.*=all:com.ibm.wsspi.wim.*=all:com.ibm.ws.wim.*=all"/>

For example:

<logging traceSpecification="*=info:com.ibm.ws.security.*=all:com.ibm.websphere.security.*=all:com.ibm.websphere.wim.*=all:com.ibm.wsspi.wim.*=all:com.ibm.ws.wim.*=all"/>
</server>

Restart the PI server process for the change to take effect.

Once you've retried the SSO test with traces enabled, examine the [PI UI Home]/wlp/usr/servers/piserver/logs/trace.log.  You may want to raise a case with IBM Support to get assistance with the trace review.  The trace is verbose and it can be difficult to isolate the most relevant messages to debug the SSO failure.