- All Implemented Interfaces:
- ITask
public class CreateSoapSTSDeployment
extends Task
This class is responsible for creating the soap-sts .war file which will expose soap-sts instances published to
a given realm. As such, it has a correspondence to the SoapSTS Agent created in a given realm.
This class will create a .war file, based off of the .war file generated by the openam-sts/openam-soap-sts/openam-soap-sts-server
module. This class will customize this .war file in the following way:
1. modify the config.properties file contained in the .war WEB-INF/classes directory to:
a. specify the user-entered soap-sts-agent username as the value corresponding to the soap_sts_agent_username property
b. specify the encrypted soap-sts-agent password as the value corresponding to the soap_sts_agent_password property
c. specify the cookie name for this OpenAM deployment as the value corresponding to the am_session_cookie_name property
d. specify the realm for this soap-sts deployment as the value corresponding to the am_realm property
e. specify the url for the OpenAM deployment as the value corresponding to the am_deployment_url property
2. include any user-specified custom wsdl files in the WEB-INF/classes directory
3. include the keystore file(s) referenced in the Soap Keystore Configuration section of any soap-sts instances published
to this realm in the WEB-INF/classes directory. The Soap Keystore Configuration entries describe the keystore location,
aliases, and passwords necessary to enforce the SecurityPolicy binding specified in the wsdl files referenced in the
soap-sts instances published in a given realm. Note that that the CXF runtime can reference keystore locations on the
filesystem, as well as the classpath, so it is not mandatory that a keystore file be included in the .war file. In addition,
for soap-sts instances protected by OpenAM session tokens protected by the transport binding, no keystore state is necessary.
Note that the first thought would be to modify the openam-soap-sts-server .war file bundled in the OpenAM .war file
(were the OpenAM build modified to effect said bundling), yet such an approach would prevent the creation of a
soap-sts .war file with soap-sts bits modified post-13 release. In other words, it would be best if this class could
create a soap-sts-agent-specific .war file based on soap-sts bits modified after the 13 release. Because there is no
generic file upload/download functionality in OpenAM, and because keystore files must be included in the soap-sts .war file, there
seems to be no other choice than to source .war file constituents from the filesystem, this despite the desire to
remove filesystem dependencies to support cloud deployments. Given the need to source .war file constituents from the
filesystem, it makes sense to also source the openam-soap-sts-server .war file from the filesystem, rather than from
the OpenAM .war file, in order that this common-task may create .war files containing post-13 release soap-sts bits.
Thus this class will write the customized .war file to the filesystem, just as the CreateFedlet common task does, but
also source keystores, custom .wsdl files, and the openam-soap-sts-server .war file from the filesystem.