weblogic

Deploying applications to WebLogic with weblogic-maven-plugin

WebLogic has made the deployment of artifacts and resources significantly easier for Maven projects through the new plugin capabilities with weblogic-maven-plugin (WLS 11) and now the wls-maven-plugin (WLS 12). The newer version of the plugin has many additional features, but also has quite a few bugs and therefore I will use the capabilities of both plugins. The general usage of the plugins is to deploy our application resources (such as JDBC and JMS configurations), our optional packages, our web applications, and also to run wlst scripts against those deployments to change their deployment order.

The plugin is not something that can be downloaded directly, it is included within the installs for WebLogic Server 11 or WebLogic Server 12. So in order to get access to the plugin, I first install both servers locally. Once I do this, I can access the plugins:

1) With WebLogic Server 11, I can build the weblogic-maven-plugin using the wljarbuilder.jar

2) With WebLogic Server 12, I can find the plugin already available via out install directory at: $MIDDLEWARE_PATH_12C_ZIP/wlserver/server/lib/wls-maven-plugin.jar

Once I have access to these plugin jars, I will load them into our Maven repository manager (which is Nexus, but also could be Artifactory…for example). This way our plugin jars will be available to all our maven projects, and I will configure them through our plugin poms.

When using the plugin for deployments, I will need to gather some information such as what environments I will be deploying the resources to, what server names are, what cluster names are, what ports, what type of resource, the name I want the deployment to be, and other information. Since the deployments will change per environment, one beneficial strategy is to design a property file per environment. Once this is complete, I can use maven property substitution to derive our deployment information dynamically during the plugin runtime from the environment specific properties.

For more details on the Properties Maven Plugin. There is one nuance or issue with this plugin that you should be aware of, is it does not support properties within a jar file. If you follow this thread in stackoverflow.com, you will see a working plugin that uses the concepts of the “Properties Maven Plugin”, but allows the reading of properties from an external jar file: properties-ext-maven-plugin. This way I can run the external properties plugin prior to the weblogic-maven-plugin to read in our environment specific properties (one jar for each environment containing specific properties for that environment).

Now I can configure our weblogic-maven-plugin within our pom file:

1
2
</p>
<plugin> <groupid>com.oracle.weblogic</groupid> <artifactid>weblogic-maven-plugin</artifactid> <version>${weblogic.version}</version> <executions> <execution> <id>deploy</id><phase>compile</phase> <goals> <goal>deploy</goal> </goals> <configuration> <adminurl>t3://${deploy.hostname}:${deploy.port}</adminurl> <user>${deploy.userId}</user><password>${deploy.password}</password> <upload>true</upload> <action>deploy</action> <targets>${target.names}</targets> <remote>true</remote> <verbose>true</verbose> <source>${project.build.directory}/lib/${deployArtifact.name}.war <name>${deploy.library.name}</name> </configuration> </execution> </executions> </plugin>
  • deploy.hostname/deploy.port = properties that are read in per environment to point to different server targets
  • deploy.userId = the userid used to login to the weblogic server
  • deploy.password = the password used to login to the weblogic server
  • target.names = the target is usually the cluster name for the environment
  • deploy.library.name = This is the name of the deployment of the console, which I may want to name differently than the war itself, since the war might contain Maven version/classifiers within the name.

Once I deploy this war, I may have the need to undeploy (which can be done via the console our through our plugin again:

1
2
</p>
<plugin> <groupid>com.oracle.weblogic</groupid> <artifactid>weblogic-maven-plugin</artifactid> <version>${weblogic.version}</version> <execution> <id>undeploy</id><phase>clean</phase><goals><goal>undeploy</goal> </goals><configuration><adminurl>t3://${deploy.hostname}:${deploy.port}</adminurl><user>${deploy.userId}</user><password>${deploy.password}</password><upload>true</upload><action>undeploy</action><targets>${target.names}</targets><remote>true</remote><verbose>true</verbose><name>${deploy.library.name}</name></configuration> </execution> </plugin>

This configuration isn’t really much different. I just don’t need to supply the source and need to change the action to undeploy.

Another feature that I may want to do and can just become tedious based on the size of our deployments is to change the deployment order. This is not something that is capable through the WebLogic Server 11 plugin, so in this case I will utilize the WebLogic Server 12 plugin. The main difference is that now I am using the WebLogic Server 12 plugin, it has the capabilities to create domains, run wlst scripting, and other features that require an installation of WebLogic Server 12. This does not necessarily mean you have to install a WebLogic Server 12 in your environments, it just means that if you are using this plugin locally or via a CI Tool such as Hudson, you will need to install a WebLogic Server 12 into that environment so that the plugin can utilize the wlst shell and other scripts in order to use the plugin. This could be an issue for developers running the scripts locally, so in this case, I utilize profiles to run plugin configurations that use WebLogic Server 12 plugin so that developers can do deployments via the WebLogic Server 11 (which has no additional dependencies) and advanced features via WebLogic Server 12.

1
2
3
4
5
6
7
</p>
<plugin><groupid>com.oracle.weblogic</groupid> <artifactid>wls-maven-plugin</artifactid> <executions><execution><phase>package</phase><goals><goal>wlst</goal></goals></execution> </executions> <configuration>      from java.util import * from javax.management import * import javax.management.Attribute
<p>
    print 'Updating deployment order .... '
</p>
<p>
    connect(System.getProperty("deploy.user"), System.getProperty("deploy.password"), System.getProperty("deploy.admin")) edit() startEdit() cd(System.getProperty("deploy.mbean")) cd(System.getProperty("deploy.library.name")) set ('DeploymentOrder', System.getProperty("deploy.order")) save() activate() disconnect()

  • deploy.user = the userid used to login to the weblogic server
  • deploy.password = the password use to login to the weblogic server
  • deploy.admin = the admin url for logging into the weblogic domain
  • deploy.mbean = AppDeployments or Libraries based on whether this is a war or something like an Optional Package
  • deploy.library.name = the exact name as it appears through JMX tree or console, for Optional Packages, this includes the version in a format such as deployName#deploySpecVersion@deployImplVersion

The space and indentation are important when including the script inline within the pom as opposed to having the wlst script as an external file. Another thing to mention is that the capability to open wlst shell, change the deployment order, and close the wlst shell appears to consume some resources and if I need to do this for multiple resources, I should do this in one connection. Otherwise I have run into issues where running this wlst plugin per resource (10+ resources) will crash our Hudson instance.

This plugin (and all the WebLogic Server 12 plugin goals) have to be run with a command line parameter to supply the installation directory for the WebLogic Server 12:

-DmiddlewareHome=%INSTALL_PATH%\Oracle\Middleware

In another post, I will explain how I utilize this plugin to deploy our Optional Packages as well as deploy our JMS/JDBC resources.

buy dianabol uk

modafinilstar

Share and Enjoy

WebLogic Encryption and Domains

When building out WebLogic domains, some of the biggest tasks to accomplish are scripting of creating a domain, scripting WebLogic resources, and utilizing our build architecture to provide jobs for pushing out resources to our WebLogic domain. The reason is I should never be manually configuring a domain because that increases the room for error when promoting domain changes between environments, and complicates the ability to rebuild a new domain based on a previous one. By scripting out the domain creation, along with the ability to promote resources via a build environment, I greatly increase the time required to build a brand new environment. The Hudson CI build server can be used to produce SCP jobs that copy necessary logging files or classpath jars, and I can utilize the maven-weblogic-plugin to deploy JMS and JDBC resources, however the plugin has bugs in deploying optional packages.

When creating WebLogic domains, I can configure the domain to be either Development or Production Modes. In order to do development against clustered environments like production environments, the WebLogic Server will be configured as “Production Mode” in all environments. The one issue that this can cause is that resources (such as JDBC Configurations) require the database password to be encrypted. In order to do this, a user must encrypt the password utilizing the domains salt file (SerializedSystemIni.dat). This can be done via command line in the WebLogic Domain, by configuring the maven exec plugin, or by using WebLogic custom APIs as in this post that has a class named SecurityHelper.

In order to encrypt passwords via a maven project, all I need to do is take advantage of the weblogic.security.Encrypt class and utilize a maven plugin that will allow us to execute it. One way to do this is to utilize the exec-maven-plugin. As the documentation describes, it helps execute system or Java programs. So in order to invoke weblogic.security.Encrypt, I will need to understand what type of parameters are necessary. The main piece of configuration it needs is the domain root directory, but it does not need this information to access any executables. It only needs this pathing because it is going to append a relative path to it (security/SerializedSystemIni.dat) to determine where the salt is located. So I can utilize this parameter to utilize different salt files for different environments (therefore enabling us to encrypt passwords for any environment I store a salt file for).

So in the following image, I have 3 environments (sandbox, development, production) and I have our salt files from the server checked into this project. I now only have to flip the env folder (like sandbox) as the WebLogic Root Domain parameter, when I want to build a password based on this env.

The following is the sample pom file which uses the mvn exec:exec plugin/goal to execute the Encrypt class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.foo</groupId>
    <artifactId>wls-env-encrypt</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <name>WLS ENV Encrypt</name>
    <packaging>pom</packaging>
    <description>Encrypts WLS JDBC Passwords - mvn exec:exec</description>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>1.2.1</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>exec</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <executable>java</executable>
                    <arguments>
                        <argument>-Dweblogic.RootDirectory=src/main/resources/${domain.root}</argument>
                        <argument>-classpath</argument>
                        <!-- automatically creates the classpath using all project dependencies,
                            also adding the project build directory -->
                        <classpath />
                        <argument>weblogic.security.Encrypt</argument>
                        <!-- Password can be supplied as an argument or entered when
                        the maven build is run -->
                        <!--argument>sample</argument-->
                    </arguments>
                </configuration>
            </plugin>
        </plugins>
    </build>
    <dependencies>
        <dependency>
            <groupId>weblogic</groupId>
            <artifactId>wlfullclient</artifactId>
        </dependency>
    </dependencies>
    <properties>
       <domain.root>sandbox</domain.root>
    </properties>
</project>

So I can invoke mvn exec:exec -Ddomain.root=dev, then the dev/security/SerializedSystemIni.dat file will be used to encrypt the properties. This greatly simplifies the creation of data sources, as an administrator doesn’t have to log into the remote server and run a shell script that invokes the Encrypt class.

But what if you have multiple domains, it would seem to complicate the issue to have all the SerializedSystemIni.dat files in SVN. This does have some benefits though incase the file/domain gets corrupted, which can happen. So to resolve this issue, I can share a salt file between multiple domains (like all non-prod servers use the same salt and all prod servers use the same salt). When WebLogic Server builds out a domain, it creates the salt file and then uses that to encrypt passwords within the config.xml and also the weblogic username/password within the boot.properties. The interesting thing is that you can override a pre-existing domains configuration with another domains configuration in order to share the salt files.

  1. Install our first non-prod domain
  2. Backup the SerializedSystemIni.dat, config.xml, and the boot.properties file
  3. Create our second non-prod domain
  4. First backup the files listed in step #2 on this second domain
  5. Copy the SerializedSystemIni.dat from our first domain to the security folder in our second domain
  6. Either do a straight copy or use a compare tool to copy over passwords from our domain one config.xml to our domain two’s config.xml
  7. Do the same thing for the boot.properties

It was really surprisingly that simple. Once the domain was brought up, I was able to use my maven project to create an encrypted password that I placed into a JDBC Resource Config file and deployed to the container and it was testable through the WebLogic console. As I stepped through this process, the domain would not correctly start if I used the wrong encrypted username/password in the boot.properties. I was able to easily resolve these issues primarly by making sure that the config.xml and boot.properties used the correct new salt for encrypting any of the passwords.

As I stated in the first paragraph, the reason for doing all these steps is really because I don’t want to be creating JDBC or JMS resources through the console. So in order to promote these types of resources via a Hudson Job, I have to figure how I would encrypt the JDBC password for the different domains (each that had their own salt file). So by utilizing the same salt in specific environments, having the salt files in SVN was more manageable and helped our ability to backup these files as well.

I have had some issues where the Managed Server fails to login with the WebLogic credentials, so the following steps are a cleaner way of backing up domain salt and config.xml, and using it to configure another domain with the same salts.

  1. Take a 64 bit (or 32 bit) domain install and backup the SerializedSystemIni.dat and the config.xml
  2. Go to another server and stop Admin/Mgd Server that is being modified.
  3. Delete data/cache under the Mgd Server
    $/servers/sandboxMgdServer1/data
    $/servers/sandboxMgdServer1/cache
  4. SCP the backed up SerializedSystemIni.dat to the server.
  5. Replace $/security/SerializedSystemIni.dat with the one that was SCP’d to the server.
  6. Vi the config.xml: $/config/config.xml and replace 3 three passwords in it with the config.xml that I backed up in step 1 (these passwords are encrypted according to the salt).
  7. Go to $/servers/sandboxAdminServer/security/boot.properties and change the user/pwd to what you want weblogic/admin
  8. Start the Admin Server Only.
  9. Copy $/servers/sandboxAdminServer/security folder to $/servers/sandboxMgdServer1/security
  10. Start the Mgd Server.

Share and Enjoy

CXF and Digital Signatures

Some web service interactions may require the use of different technologies that are under the umbrella of WS-Security. One of those requirements is driven by the need for specific parts of the message to contain metadata to ensure that the intended sender actually created that part of the message. This can resolved by applying a Digital Signature. I can create a unique Digital Signature (like our own personal signature) and then I can sign parts of the message (as if you were initialing different parts of a contract). Thomas Erl’s site (What is SOA) defines it as this:

XML-Digital Signatures establishes a standardized format for representing digital signature data. Digital signatures establish credibility within a message, as they assure the recipient that the message was in fact transmitted by the expected partner service. It also provides a means of communicating that the message contents were not altered in transit, as well as support for standard non-repudiation. As with the XML-Encryption standard, XML-Digital Signature also supports binary and textual data.

So I am going to be utilizing functionality provided by CXF to implement Digital Signatures. The details of the properties and features of Digital Signatures sometimes seem hard to find, but luckily CXF (like most Web Service frameworks such as Axis or Spring Web Services Framework) utilizes WSS4J to do much of the actual signature part of the message (as well as Username Token, SAML, etc.). In order to get Digital Signatures to work in CXF, I am going to take advantage of CXF’s Interceptors, as well as Spring’s util namespace for representing properties, and finally some modifications to our startup scripts for WebLogic Server because of issues with jar files that are used.

In this example, I want to go one step further and also provide a Timestamp that is signed, because my service provider only allows Digital Signature requests within a certain timeframe to prevent highjacking of the message (for instance if the message is signed at 11:00 AM and the request isn’t received at the service provider until 11:05 AM, the service provider can read the Timestamp and see that it has been signed…to verify that it wasn’t altered and reject the message because it is outside of the required one minute timeframe for a request). Once I have the Signature piece complete, adding a Timestamp requirement is absolutely simple.

So just as I mentioned in my other post about CXF and 2-way SSL, I will need to create a Java Keystore that is separate from our other keystore since Digital Signatures will allow us to provide the alias for our cert, while 2-way SSL configuration does not. So I will create our keystore and provide a password for it. Unlike the 2-way SSL that requires a Certificate Authority keystore, which I created a custom one and put it as a startup parameter for WebLogic Server, I will not be doing that for this keystore because I have multiple keystores for different security requirements and services.

Much of the source example here is leveraged and taken from David Valeri – CXF with WS* Example.

So first thing I need to do is define a bean for SAAJ and then register that with our JaxWsProxyFactoryBean:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<bean id="saajOutInterceptor" class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>

<bean id="secureWebServiceProxyFactory" class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean" lazy-init="true">
    <property name="serviceClass" value="com.foo.SecureWebService"/>
    <property name="address" value="${secure.service.url}"/>
    <property name="inInterceptors" ref="logInbound"/>
    <property name="outInterceptors">
        <list>
            <ref bean="saajOutInterceptor"/>
            <ref bean="secureWebServiceWss4jOutInterceptor"/>
            <ref bean="logOutbound"/>
        </list>
    </property>
</bean>

The next part is deciding which actions I am going to do and what type of information I need for those actions. So I will be doing “Timestamp Signature” to signify that I want to Timestamp our outbound request as well as apply a Digital Signature. The Digital Signature needs information such as the certificate alias, how to attach the key (which can be the most complicated piece for me in order to get the Signature correctly received by the provider), which parts of the message I want to sign, I can select the properties file which will provide the necessary information for WSS4J, the signature digest algorithm, and a password callback handler instance. The reason the example I referenced above is so beneficial, is because I really don’t want an external properties file. So as the example shows, I can utilize Spring’s util namespace to represent the properties that are required for WSS4J and I can reference this properties bean via the SignaturePropRefId.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<bean id="secureWebServiceWss4jOutInterceptor" class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
  <constructor-arg>
        <map>
           <entry key="action" value="Timestamp Signature"/>
           
           <!-- This is the fallback user for sig/enc if the sig/enc specific
            properties are not set.  We shouldn't need this, but the WSS4JOutInterceptor
            (CXF 2.2.2.2) looks for it and fails if it is not set. -->
           <entry key="user" value="${secureWebService.keystore.alias}"/>
           
           <!-- The certificate alias in the signature crypto config to sign
            the message with.  The password is retrieved from the callback handler. -->
           <entry key="signatureUser" value="${secureWebService.keystore.alias}"/>
           
           <!-- Signature key attachment method.  We want to put the token
            directly in the header and not use a reference. -->
           <entry key="signatureKeyIdentifier" value="DirectReference"/>
           <!--entry key="signatureKeyIdentifier" value="X509KeyIdentifier"/-->
           
           <!-- The parts of the response to sign.  Include: Body,
            token, timestamp, and addressing headers. -->
           <entry key="signatureParts" value="{http://schemas.xmlsoap.org/soap/envelope/}Body;{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{http://www.w3.org/2005/08/addressing}MessageID"/>
           
           <!--entry key="signaturePropFile" value="${secureWebService-wss4j.properties}"/-->
           <!-- Defines the property name that contains a Properties object with the desired
             settings in it.  Better than loading a static file from the classpath when using
            Spring. -->
           <entry key="SignaturePropRefId" value="cryptoProperties" />
           
           <!-- The entry that actually contains the Properties object for
            the signature crypto configuration.  See SignaturePropRefId. -->
           <entry key="cryptoProperties" value-ref="secureWebServiceCryptoProperties" />

           <!-- The algorithm used to create the actual signature data. -->
           <!--entry key="signatureAlgorithm" value="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/-->

           <!-- The algorithm used to create digests of message content. -->
           <!-- <entry key="signatureDigestAlgorithm" value="http://www.w3.org/2001/04/xmlenc#sha256"/> -->
           <!--entry key="signatureDigestAlgorithm" value="http://www.w3.org/2000/09/xmldsig#sha1"/-->

           <!-- The reference to the callback handler for retrieving passwords
            for private keys in the signature and encryption crypto configurations. -->
           <entry key="passwordCallbackRef">
                <bean class="com.foo.PasswordCallbackHandler">
                    <property name="password" value="${secureWebService.keystore.password}"/>
                </bean>
            </entry>
        </map>
     </constructor-arg>
  </bean>

<!-- Define a Properties object with the properties required by the
       org.apache.ws.security.components.crypto.Merlin WSS4j Crypto implementation.
       This crypto config is used for signature creation and validation and decryption. -->
  <util:properties id="secureWebServiceCryptoProperties">
    <!-- Defines the implementation class. -->
    <prop key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop>
    <!-- Defines the location, on the classpath, of the keystore file.  Also
         takes URL or file path. Not applicable when using PKCS 11. -->
    <prop key="org.apache.ws.security.crypto.merlin.file">${secureWebService.keystore.file}</prop>
    <!-- The type of the keystore pointed to by org.apache.ws.security.crypto.merlin.file. -->
    <prop key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
    <!-- The crypto provider that can load the keystore. -->
    <!--prop key="org.apache.ws.security.crypto.merlin.keystore.provider"></prop-->
    <!-- The password for the keystore file. -->
    <prop key="org.apache.ws.security.crypto.merlin.keystore.password">${secureWebService.keystore.password}</prop>
    <!-- The alias for the default private key to use.  Not required.
    <prop key="org.apache.ws.security.crypto.merlin.cert.provider"></prop>-->
    <prop key="org.apache.ws.security.crypto.merlin.keystore.alias">${secureWebService.keystore.alias}</prop>
    <!-- If the JVM cacerts file contents should be loaded into the trust chain.
    <prop key="org.apache.ws.security.crypto.merlin.load.cacerts">false</prop> -->
    <!-- If the JVM cacerts file is used, the password for the file.
    <prop key="org.apache.ws.security.crypto.merlin.cacerts.password"></prop> -->
  </util:properties>

So you can see by the signatureParts that I am signing the Body, the Timestamp, and part of the Address. The reason I am signing part of the Address is just like our reasons for the Timestamp, in this case the service provider requires WS-Addressing, and by signing it, I am providing the necessary integrity that the intended client that made the original request is providing the Addressing information without being altered. All of the values in this configuration are provided through a security.properties file that is external to our war (I will talk about this later in utilize WebLogic Optional Packages to create a jar containing our enterprise properties so that the war does not have hard-coded properties per environment).

1
<context:property-placeholder location="classpath*:/enterprise.properties" />

So I wish that this was all that was required, but it is unfortunately not because of the fact that I am running on WebLogic Server. If you have run the latest Hibernate/JPA with WebLogic, you have probably had to make the same types of modification to the startup scripts. Here is some parameters that I had to include, along with adding the saaj jar onto our preclasspath:

1
2
SAAJ_JAVA_OPTIONS="-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl -Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl"
SAAJ_PRECLASSPATH="$/saaj-impl-1.3.2.jar"

The last piece that really caused me grief was around the version of the JDK I was using and whether or not I needed references to Bouncycastle APIs. And as the following post on CXF’s forum suggests, I no longer need this API because of the features in JDK 6 and therefore I had to remove any references/dependencies on Bouncycastle (as it caused our Digital Signatures) to fail.

http://cxf.547215.n5.nabble.com/java-lang-NoClassDefFoundError-org-bouncycastle-asn1-pkcs-PrivateKeyInfo-td4710843.html

And as I mentioned in the CXF and 2-way SSL thread, I required the additional cryptography libraries in order to digitally sign the message: Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files

Resources related to this subject:

Apache CXF – WS-Security Add Interceptors
Adding X.509 security headers to Apache CXF SOAP calls (WS-SecurityPolicy method)
Adding X.509 security headers to Apache CXF SOAP calls
WSS4J Javadoc – Constants
Java Cryptography Architecture Standard Algorithm Name Documentation
Apache CXF Tutorial – WS-Security with Spring
David Valeri – CXF with WS* Example
JBoss – Turn on WS-Security
Securing your Web services with Spring-WS
Sending WS-Security Signature and Encryption Profiles to Axis2/Rampart Web service
An Overview of the WS-Security Framework

Forum posts related to this subject:

http://cxf.547215.n5.nabble.com/CXF-with-Digital-Signatures-td3408690.html
http://cxf.547215.n5.nabble.com/KeyName-within-a-Digital-Signature-Configurable-td4656619.html
http://cxf.547215.n5.nabble.com/java-lang-NoClassDefFoundError-org-bouncycastle-asn1-pkcs-PrivateKeyInfo-td4710843.html
http://cxf.547215.n5.nabble.com/JaxWsProxyFactoryBean-amp-WS-Addressing-in-Configuration-td4683953.html
http://cxf.547215.n5.nabble.com/Send-X509Certificate-with-request-td564722.html

limo service austin tx

Share and Enjoy