Skip navigation
All People > SungHoon_Kim > Sung Hoon Kim's Blog > 2016 > January > 18

Title:

Is RelayState part of signature verification?

 

Description:

- SP Initiated Federation is resulting in Failed to Verify Signature.

- IDP Initiated Federation is working fine.

- Comparing the working and failing SP Initiated Federation appears to be change in the RelayState query parameter.

 

-----------------------------------------------------

 

Question:

Is RelayState part of signature verification?

 

Answer:

RelayState is indeed part of signature verification.

Signature Verification at the IDP will fail for the AuthnRequest if there is a change to the RelayState value.

For example,

     * Upper case and Lower case changes.

     * URL Encoding and decoding differences.

     * Change in the RelayState value itself.

 

Additional Information:

- http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf #Page 16. #3.4.3 RelayState

 

** This article is now published as a KB article linked below.

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec1247034.aspx

Title:

    - Troubleshooting CA Access Gateway startup issues

 

Description:

    - You have newly installed CA Access Gateway and it fails to startup.

    - CA Access Gateway has been working fine and suddenly fails to startup.

 

 

Introduction / Summary: 

CA Access Gateway is an Apache + JK Connector + Tomcat bundle.

It also comes with some applications(localapps) that are deployed.

The common places causing startup issues are :

1. Apache Certificate settings

2. Tomcat configuration

3. Tomcat localapps

This is to assist in isolating the startup problems before submitting support ticket for assistance.

 

Instructions:

First of all, run "netstat -an" to see which service is able to startup.

Check if you are seeing port 80 and 443 (if SSL enabled) for apache.

Check if you are seeing port 8080(HTTP), 543(HTTPS), 8005(SHUTDOWN) and 8009(AJP) for tomcat.

 

1. For apache side problem

Enable LogLevel in httpd.conf file to debug

Check the error_log to determine which configuration is causing problem.

 

2. For tomcat side problem

Check the server.log to determine if there are any exceptions and if they point to any particular feature.

In case of Windows, you can try starting up tomcat from command-line by copying SmSpsProxyEngine.properties to SmSpsProxyEngine.bat

And add the following line(which is a copy of NETE_SPS_PROXY_ENGINE_CMD) at the most bottom.

SmSpsProxyEngine.bat (last line of)
"%NETE_SPS_JAVA_HOME%\bin\java.exe" -Xms512m -Xmx1024m -XX:MaxPermSize=256M -Dcatalina.base="%NETE_SPS_TOMCAT_HOME%" -Dcatalina.home="%NETE_SPS_TOMCAT_HOME%" -Djava.endorsed.dirs="%NETE_SPS_TOMCAT_HOME%\endorsed" -Djava.io.tmpdir="%NETE_SPS_TOMCAT_HOME%\temp" -DHTTPClient.log.mask=0 -DHTTPClient.Modules="HTTPClient.RetryModule|org.tigris.noodle.NoodleCookieModule|HTTPClient.DefaultModule" -Dlogger.properties="%NETE_SPS_TOMCAT_HOME%/properties/logger.properties" -DSM_AGENT_LOG_CONFIG="%STS_AGENT_LOG_CONFIG_FILE%" -classpath "%NETE_SPS_TOMCAT_HOME%\bin\proxybootstrap.jar;%NETE_SPS_TOMCAT_HOME%\properties;%NETE_SPS_JAVA_HOME%\lib\tools.jar;%NETE_SPS_TOMCAT_HOME%\bin\bootstrap.jar;%NETE_SPS_ROOT%\resources;%NETE_SPS_ROOT%\agentframework\java\cryptoj.jar" com.netegrity.proxy.ProxyBootstrap -config "%NETE_SPS_ROOT%/proxy-engine/conf/server.conf"

In case of Unix, simply run the "proxyserver.sh" command to startup tomcat from shell. This file has the similar content available in the SmSpsProxyEngine.properties file.

Look for exception errors.

You can add -verbose to the above in case if it is suspected that certain jar files are not being loaded.

 

The default loglevel for server.log file is "INFO" and is sufficient in most cases but can be increased if needed.

<SPS_HOME>/secure-proxy/Tomcat/properties/logger.properties

Change from

log4j.rootCategory=INFO.SvrFileAppender

to

log4j.rootCategory=ALL.SvrFileAppender

 

3. For tomcat localapps

In server.conf file there are <Contexts> section that lists the deployed localapps.

Each <Context> comes with a switch to enable separately.

Try disabling all the localapps to see if the CA Access Gateway starts up.

Then you can try enabling them one by one to determine which app was causing initialization failure.

<Contexts>

  <Context name="Service name1">

    ***="yyy"

    enable="yes"

  </Context>

  <Context name="Service name2">

    ***="yyy"

    enable="yes"

  </Context>

</Contexts>

 

Additional Information:

This article covers only the startup issues.