This documentation supports the 9.1 to 9.1 Service Pack 3 version and its patches of BMC Atrium Core. The documentation for version 9.1.04 and its patches is available here.

To view the latest version, select the version from the Product version menu.

Apache Axis2 and BMC Atrium Core Web Services

The BMC Atrium Core Web Services Infrastructure uses Apache Axis2, and the BMC Atrium Core Registry is the Apache jUDDI Server. Apache Tomcat hosts the BMC Atrium Web Application Archive and the BMC Atrium Web Services Archive.

BMC Atrium Web Application Archive and Axis2 modifications

The BMC Atrium Web Application Archive (BMC Atrium WAR) is installed as the atriumws91.war file that includes the following distributions.

Modified JAR and MAR files include BMCSoftwareModified-atriumws91 in the file names. For example, rampart-1.5.mar is renamed to rampart-1.5-BMCSoftwareModified-atriumws91.mar.

Applied solution 4.2 as defined in Apache Axis2 Security Advisory (CVE-2010-1632). All occurrences of axis2.xml are modified as per solution specifications.

  • Apache Axis2 WAR Distribution version 1.5.1 — This distribution has no direct modification in the source code. The modifications are limited to the WEB-INF/conf/axis2.xml and WEB-INF/axis2.xml files. For more information, see Apache Axis2 WAR Distribution modifications.
  • Apache Rampart version 1.5 — This distribution (rampart-1.5-BMCSoftwareModified-atriumws91.mar ) has several direct modifications to the source to overcome unwanted behaviors when using Rampart Basic configuration. For more information, see Apache Rampart modifications.
  • Apache WSS4J version 1.5.8 — Normally, WSS4J 1.5.8 is included as a part of Apache Rampart 1.5. However, the included Apache WSS4J distribution (wss4j-1.5.8-BMCSoftwareModified-atriumws91.jar ) has source code modifications in a few specific areas to overcome non-compliant behaviors in the formation of wsu:Id attributes during the formation of SOAP responses. For more information, see Apache WSS4J modifications.
  • Bouncy Castle Crypto APIs for Oracle Java version 1.4.5 — This binary distribution is included without modifications. It replaces Bouncy Castle Crypto APIs for Java version 1.4, which is distributed with the binary distribution of Rampart version 1.5. That version is not be included in the BMC Atrium WAR.

The atriumws91.war file also includes the following custom modules:

  • BMCAtriumWSEncryptionEnforcer — This module enforces encryption of the wsse:UsernameToken element at the element level and the SOAP:Body element at the content level.
  • BMCAtriumWSSignatureBlocker — This module blocks any messages that have been signed using an unaccepted key and algorithm pair.
    • This module prevents a SOAP:Request from being executed when the security policy for encrypting responses is enabled and when the private key that the client uses to sign its requests is of DSA type. BMC Remedy IT Service Management Web Services only supports encryption of the SOAP:Response using the public certificate that the client uses to sign his SOAP:Request. The public certificate is included with the SOAP:Request. Because a DSA key cannot be used to encrypt a SOAP response using the available RSA key wrap algorithms in signing the response, this attempt fails in these particular combination of circumstances.
      However, a request signed with a DSA key does not always fail. If the policy for encrypting the SOAP:Response is not enabled, requests signed with a DSA signature are acceptable, and this module does not block the DSA signature.
    • This module also prevents the use of unsupported algorithms for signatures. Only RSA-SHA1 and DSA-SHA1 algorithms are allowed. Any signature algorithm that does not match these is blocked. DSA-SHA1 is also blocked if outgoing encryption of the SOAP:Response is enabled
  • BMCAtriumWSResponseRepair — When referenced at a context level that affects the service and operation in question, such as the Configuration context (axis2.xml ) or the Service context (services.xml ), this module attempts to repair any and all outgoing messages by ensuring that the xsi namespace is defined at the top level in the SOAP:Envelope element. This prevents potential errors with messages secured by encryption from failing to be unwrapped by specific clients (such as WSS4J-based clients) when the wsi namespace declaration is contained with encrypted elements but not in an exposed plaintext parent element.
Was this page helpful? Yes No Submitting... Thank you