Troubleshooting
Problem
Collecting data for Web Single Sign-on (WebSSO) problems with IBM WebSphere® Application Server versions 8.5 and 9.0 and Liberty. Gathering this MustGather information before you call IBM support can help you understand the problem and save time analyzing the data.
Resolving The Problem
This document describes how to obtain the following troubleshooting data for the SSO components:
Trace from server startup (trace.log files)
Browser trace (HAR files)
Configuration information Diagnostic questions
|
The Web Single Sign-on (SSO) components include:
|
- SSO trace specifications
Avoid delay: The SSO runtimes emit configuration data in the trace only during server startup. Therefore, you must gather traces to send to IBM support from server startup.
- WebSphere traditional
Enter WebSphere traditional trace strings as one line with no breaks or spaces.
AllThis trace specification is for all SSOs together. Use this one if you're unsure of what you should choose.*=info:com.ibm.ws.security.web.*=all:com.ibm.ws.security.oidc.*=all:com.ibm.ws.security.openidconnect.*=all:com.ibm.ws.security.openid20.*=all:com.ibm.ws.security.saml.*=all:com.ibm.websphere.wssecurity.*=all:com.ibm.ws.wssecurity.*=all:com.ibm.ws.wssecurity.platform.audit.*=off:SamlCommandProviderImpl=all:com.ibm.ws.security.oauth20.*=all:com.ibm.oauth.*=allOpenID Connect (OIDC), OpenID 2.0, and JWT authentication
OAuth provider
SAML Web Single Sign On*=info:com.ibm.ws.security.web.*=all:com.ibm.ws.security.saml.*=all:com.ibm.websphere.wssecurity.*=all:com.ibm.ws.wssecurity.*=all:com.ibm.ws.wssecurity.platform.audit.*=off:SamlCommandProviderImpl=all
SAML Web Single Sign On with WS-SecurityDo not use this trace specification unless you are directed to do so by support.
SAML Web Inbound*=info:com.ibm.ws.security.web.*=all:com.ibm.websphere.wssecurity.*=all:com.ibm.ws.wssecurity.*=all:com.ibm.ws.wssecurity.platform.audit.*=off - Liberty
OpenID Connect (OIDC), OpenID 2.0, OAuth, and JWT authentication
SAML Web Single Sign Oncom.ibm.ws.security.*=all:com.ibm.ws.webcontainer.*=all:org.apache.xml.security.*=all:com.ibm.ws.http.*=all:com.ibm.ws.ssl.*=all:com.ibm.ws.channel.ssl.*=all:com.ibm.ws.transport.http.*=all:com.ibm.websphere.channelfw.ChannelUtils=all:org.opensaml.*=all:io.openliberty.security.*=allAllcom.ibm.ws.security.*=all:com.ibm.ws.webcontainer.security.*=all:com.ibm.oauth.*=all:com.ibm.wsspi.security.oauth20.*=all:org.openid4java.*=all:org.apache.http.client.*=all:org.apache.xml.security.*=all:com.ibm.ws.http.*=all:com.ibm.ws.ssl.*=all:com.ibm.ws.channel.ssl.*=all:com.ibm.ws.transport.http.*=all:com.ibm.websphere.channelfw.ChannelUtils=all:org.opensaml.*=all:io.openliberty.security.*=all
- WebSphere traditional
- Collect data for WebSphere traditional
This section is for collecting data for WebSphere traditional. If you want to collect data for Liberty, see the Collect data for Liberty section later in this document.
To troubleshoot an SSO problem in WebSphere traditional, collect the information listed in the step-by-step instructions in this section.
When all the information for your issue is ready, follow the instructions on Exchanging information with IBM Technical Support for problem determination to send the information and files that you collected.Items to collectComments / Instructions1. Problem description Provide a clear, specific problem description, including specific usage information and error scenario. 2. Diagnostic questions - When does the problem occur?
- How often does the problem occur?
- Did this work in the past? If so, did you make any changes to the system or SSO configuration? Explain.
3. Single Sign-on configuration
informationGather the following files: - (was_profile_root)/config/cells/(cell_name)/security.xml
- For OAuth issues only:
- A recursive archive file of (was_profile_root)/config/cells/(cell_name)/oauth20
4. Single Sign-on trace Enable the Web Single Sign-on tracing that you want and reproduce the problem.
Avoid delay: You must gather SSO traces from server startup to confirm that the components initialized without error.
1. Determine your trace specification- Expand the Trace specifications section earlier in this document.
- Note the trace specification that you need to use based on the TAI that you are using.
- Return to this step.
2. Enable trace- In the administrative console, expand Troubleshooting and select Logs and Trace.
- On the Logging and Tracing page, select your server and then Diagnostic Trace.
- Under Trace Output, select File.
- The default values for Maximum File Size and Maximum Number of Historical Files are sufficient if you can re-create the problem with one request. However, if the problem is intermittent, it is necessary to increase the File Size to 50 MB and set an appropriate number of historical files.
- Click OK and save your configuration.
- Again expand Troubleshooting and select Logs and Trace.
- In the Logging and Tracing page, select your server and then Change Log Detail Levels.
- Enter the trace string that you chose earlier in the Determine your trace specification step.
- Click OK and save your configuration.
- Proceed to 'Reproduce the problem'
3. Reproduce the problemAvoid delay: You must gather SSO traces from application server startup. - On your application server on which the TAI is configured, do the following:
- Stop the application server
- Restart the application server
- Start a browser trace
- Reproduce the problem, taking note of any relevant user and group names used, exact URL strings accessed, and general time stamps.
4. Locate the trace fileOn a WebSphere traditional server, you can find the trace in the following location: - (was_profile_root)/logs/(server_name)/trace*.log
Follow instructions to send diagnostic information to IBM support to send the files mentioned in the preceding steps.
- Collect data for Liberty
This section is for collecting data for Liberty. If you want to collect data for WebSphere traditional, see the Collect data for WebSphere traditional section earlier in this document.
To troubleshoot an SSO problem in Liberty, collect the information listed in the step-by-step instructions in this section.
When all the information for your issue is ready, follow the instructions on Exchanging information with IBM Technical Support for problem determination to send the information and files that you collected.Items to collectComments / Instructions1. Problem description Provide a clear, specific problem description, including specific usage information and error scenario. 2. Diagnostic questions - When does the problem occur?
- How often does the problem occur?
- Did this work in the past? If so, did you make any changes to the system or SSO configuration? Explain.
3. Single Sign-on configuration
informationGather the following files:
- At a minimum, send the server.xml file and idpMetadata.xml file (for SAML).
- If you can obtain a recursive archive file of your Liberty installation, and that archive file is 500 mb or smaller, send a compressed, recursive archive file of your Liberty installation directory.
4. Single Sign-on trace Enable the Web Single Sign-on tracing and reproduce the problem.
Avoid delay: You must gather SSO traces from server startup to confirm that the components initialized without error.
1. Determine your trace specification- Expand the Trace specifications section earlier in this document.
- Note the trace specification that you need to use based on the feature that you are using.
- Return to this step.
2. Enable trace- Follow the instructions in the Enabling Trace on Liberty section in Setup trace and get a full dump for WebSphere Liberty.
- See the Liberty: Logging and Trace topic in the IBM Documentation.
- Use the trace string that you chose earlier in the Determine your trace specification step.
- Proceed to 'Reproduce the problem'.
3. Reproduce the problemAvoid delay: You must gather SSO traces from application server startup. - On your Liberty server on which the feature is configured, do the following:
- Stop the Liberty server.
- Restart the Liberty server.
- Start a browser trace:
- Reproduce the problem, taking note of any relevant user and group names used, exact URL strings accessed, and general time stamps.
4. Locate the trace and log filesOn Liberty, by default, you can find the trace in the following location:
- (wlp.install.dir)/usr/servers/(server_name)/logs
If you do not see your trace in that directory, find the log directory configured on the logDirectory attribute in your server.xml file.
5. Recursive archive the logs directoryRecursive archive the directory that you identified in the previous step and send in the file. This action gathers the following files:console.log
messages.log
trace.log
ffdc/*
Follow instructions on Exchanging information with IBM Technical Support for problem determination to send the files mentioned in the preceding steps.
- Exchange data with IBM Support
To diagnose or identify a problem, it is sometimes necessary to provide Technical Support with data and information from your system. In addition, Technical Support might also need to provide you with tools or utilities for you to use during problem determination. You can submit files by using one of the following methods to help speed problem diagnosis:
- Service Request (SR)
- FTP to the Enhanced Customer Data Repository (ECuRep)
Exchanging information with IBM Technical Support for problem determination
Related Information
Was this topic helpful?
Document Information
Modified date:
06 February 2024
UID
swg21971762