IS 2.0.2 release is available for download at [1].

This is based on revolutionary the WSO2 Carbon [2] framework, Middleware
a la carte’.

All the major features have been developed as pluggable Carbon components.

New Features
—————

1. Various bug fixes and enhancements including architectural improvements to Apache Axis2, Apache Rampart, Apache Sandesha2 , WSO2 Carbon and other projects.
2. Equinox P2 based provisioning support –  extend your IS instance by installing new P2 features [5].

Other Key Features
———————
1. Entitlement Engine with XACML 2.0 support.
2. Claim based Security Token Service.
3. Extension points for SAML assertion handling.
4. OpenID Provider
5. Information Card Provider
6. SAML 2.0 Token Profile support
7. Passive STS

How to Run
——————
1. Extract the downloaded zip.
2. Go to the bin directory in the extracted folder.
3. Run the wso2server.sh or wso2server.bat as appropriate.
4. Point your browser to the URL https://localhost:9443/carbon
5. Use “admin”, “admin” as the user name and password.
6. If you need to start the OSGi console with the server use the
property -DosgiConsole when starting the server

Known issues
———————-
All the known issues have been filed here [3]. Please report any other
issues you find as JIRA entries.

Contact us
—————–
WSO2 Identity Server developers can be contacted via the mailing lists:
For Users: carbon-user@wso2.org
For Developers: carbon-dev@wso2.org

Alternatively, questions can also be raised in the Identity Server forum
at http://wso2.org/forum/308

Training
—————
WSO2 Inc. offers a variety of professional Training Programs, including
training on general Web services as well as WSO2 Identity Server,
Apache Axis2, Data Services and a number of other products. For
additional support information please refer to
http://wso2.com/training/course-catalog/

Support
————–
WSO2 Inc. offers a variety of development and production support
programs, ranging from Web-based support up through normal business
hours, to premium 24×7 phone support. For additional support information
please refer to http://wso2.com/support/

For more information on WSO2 Identity Server, visit the WSO2 Oxygen Tank[4].

Thank you for your interest in WSO2 Identity Server.

-The WSO2 Identity Server team

[1]: http://wso2.org/downloads/identity
[2]: http://wso2.org/projects/carbon
[3]: https://wso2.org/jira/browse/CARBON
[4]: http://wso2.org
[5]: https://wso2.org/wiki/display/carbon/p2-based-provisioning-support

1. As the first step you need to set up Apache Axis2 + Rampart. You can download Axis2 1.5 from here and Rampart 1.5 from here.(Since Rampart 1.5 is not released yet, I have hosted the binaries built from the 1.5 branch) I am using an Axis2 deployment on Apache Tomcat to host services in this post.

• You can simply download Axis2 webapp and deploy it in Apache Tomcat. (I am referring the tomcat installation directory as TOMCAT_HOME from here onwards)
• Copy the set of jars inside the lib directory of Rampart binary distribution into $TOMCAT_HOME/webapps/axis2/WEB-INF/lib and copy the rampart and rahas module archives(.mar) files into $TOMCAT_HOME/webapps/axis2/WEB-INF/modules directory. Rampart makes use of WSS4J for SAML token validation. Because WSS4J release with the SAML 2.0 token validation support is yet to be released, I am using a custom WSS4J implementation in this scenario. Please download wss4j-1.5.7.wso2v2.jar from here and replace the wss4j-1.5.8.jar which is shipped with Rampart.
• To use SAML 2.0 support, it is required to endorse the default JAXP implementation of the JDK with Apache Xerces and Xalan. You can find more information on how to endorse the JDK in the README file of Rampart binary distribution. Since Tomcat uses its own endorsed directory, it is required to endorse the Tomcat deployment. You can copy the same set of jar files which is used to endorse the JDK to $TOMCAT_HOME/endorsed directory. For convenience, I have hosted the necessary endorsing jars here. You can download this set of jars and copy them to $JAVA_HOME/jre/lib/endorsed directory.

2. As the second step you need to set up the STS and the relying party service. I am using the SAML 1.1 sample shipped with Apache Rampart with some modifications to make it use SAML 2.0. We are using a service archive which contains both relying party service and configurations for STS. STS is implemented inside Rampart and it is sufficient to provide only the configuration. You can download the this service archive named “samlple05.aar” from here. This service archive will contain a service group where STS and Sample05 are the members of that service group.

• It is possible to configure STS according to the user requirements. STS configuration of this sample can be found in services.xml file inside the META-INF directory of the extracted service archive. These configurations are available in the <parameter name=”saml-issuer-config”> element. Lets go through some of the important parameters of this configuration.
  • issuerName – This is used to identify the issuer, this could be the end point of the issuer or any other identifier used by the relying party services.
  • issuerKeyAlias – This is the alias of the certificate that STS will be using for signing SAML Assertions.
  • issuerKeyPassword – Private key password of the certificate of the STS
  • cryptoProperties – The child elements of this configuration element is used to identify the keystore which is used by the STS. Location of the keystore, keystore type and keystore password are specifed as child elements of this parameter.
  • timeToLive – Validity period of a SAML assertion(mentioned in seconds)
  • trusted-services – Under this parameter, you can specify the EPRs of the trusted relying party services for which users are obtaining SAML tokens. It is possible to specify a wildcard character, so that STS trusts any relying party service. In this sample, we have used a wildcard character. But in real world scenarios, it is recommended not to use this and mention the trusted services specifically.
• STS is a web service, hence it is possible to publish its requirement as a policy. Please note that, it is better if STS can express its authentication requirements for the user in its policy. In this case, we are using a security policy which contains a Asymmetric Binding. So the X.509 certificate of the client is used to authenticate him.
• Then it contains the policy and configuration required for the relying party service (sample05) which has a ‘echo’ operation. The security policy of the relying party service imposes the presence of a SAML 2.0 token in the SAML request.

<sp:SupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                                <wsp:Policy>
       <sp:IssuedToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
           <Issuer xmlns="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
               <Address xmlns="http://www.w3.org/2005/08/addressing">https://kirillgdev04/Security_Federation_SecurityTokenService_Indigo/Symmetric.svc/Scenario_1_IssuedTokenOverTransport_UsernameOverTransport</Address>
           </Issuer>
           <sp:RequestSecurityTokenTemplate>
              <t:TokenType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">urn:oasis:names:tc:SAML:2.0:assertion</t:TokenType>
              <t:KeyType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</t:KeyType>
              <t:KeySize xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">256</t:KeySize>
           </sp:RequestSecurityTokenTemplate>
           <wsp:Policy>
             <sp:RequireInternalReference/>
           </wsp:Policy>
      </sp:IssuedToken>
   </wsp:Policy>
 </sp:SupportingTokens>

This policy assertion establishes the requirement for a SAML 2.0 assertion which uses a symmetric key with a length of 256 bit for SAML subject confirmation. These requirements are specified in the RequestSecurityTemplate policy assertion.

• Then lets deploy this service archive in Axis2. You can simply copy sample05.aar file into $TOMCAT_HOME/webapps/axis2/WEB-INF/services/ directory and restart Tomcat if you haven’t enable hot deployment.

3. Now lets look at the client code.

package org.wso2.sts;                                                                            

import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axiom.om.impl.builder.StAXOMBuilder;
import org.apache.axiom.soap.SOAP12Constants;
import org.apache.axis2.addressing.AddressingConstants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.neethi.Policy;
import org.apache.neethi.PolicyEngine;
import org.apache.rahas.RahasConstants;
import org.apache.rahas.Token;
import org.apache.rahas.TokenStorage;
import org.apache.rahas.TrustException;
import org.apache.rahas.TrustUtil;
import org.apache.rahas.client.STSClient;
import org.apache.rampart.RampartMessageData;
import org.apache.ws.secpolicy.SP11Constants;
import org.apache.ws.secpolicy.SPConstants;
import org.opensaml.XML;

import javax.xml.namespace.QName;

public class Client {

 public static void main(String[] args) throws Exception {

 //TODO : replace with the local paths in your machine
 String epr = "http://localhost:8081/axis2/services/sample05";
 String repo = "/path/to/repo";
 String servicePolicy = "/path/to/service-policy.xml";
 String stsPolicy = "/path/to/sts-policy.xml";

 ConfigurationContext ctx = ConfigurationContextFactory.createConfigurationContextFromFileSystem(repo, null);

 STSClient stsClient = new STSClient(ctx);

 stsClient.setRstTemplate(getRSTTemplate());
 stsClient.setVersion(RahasConstants.VERSION_05_12);
 String action = TrustUtil.getActionValue(RahasConstants.VERSION_05_02, RahasConstants.RST_ACTION_ISSUE);
 stsClient.setAction(action);

 //Obtain the token
 Token responseToken = stsClient.requestSecurityToken(loadPolicy(servicePolicy),
 "http://localhost:8081/axis2/services/STS", loadPolicy(stsPolicy), epr);

 System.out.println("\n------------------------------ Requested Token ---------------------------------------\n");
 System.out.println(responseToken.getToken().toString());

 TokenStorage store = TrustUtil.getTokenStore(ctx);
 store.add(responseToken);

 //Call the relying party service
 ServiceClient client = new ServiceClient(ctx, null);

 Options options = new Options();
 options.setAction("urn:echo");
 options.setTo(new EndpointReference(epr));
 options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, loadPolicy(servicePolicy));
 options.setProperty(RampartMessageData.KEY_CUSTOM_ISSUED_TOKEN, responseToken.getId());
 client.setOptions(options);

 client.engageModule("addressing");
 client.engageModule("rampart");

 OMElement response = client.sendReceive(getPayload("Hello world1"));
 System.out.println("Response  : " + response);

 }

 private static Policy loadPolicy(String xmlPath) throws Exception {
 StAXOMBuilder builder = new StAXOMBuilder(xmlPath);
 return PolicyEngine.getPolicy(builder.getDocumentElement());
 }

 private static OMElement getPayload(String value) {
 OMFactory factory = OMAbstractFactory.getOMFactory();
 OMNamespace ns = factory.createOMNamespace("http://sample05.policy.samples.rampart.apache.org", "ns1");
 OMElement elem = factory.createOMElement("echo", ns);
 OMElement childElem = factory.createOMElement("param0", null);
 childElem.setText(value);
 elem.addChild(childElem);

 return elem;

 }

 private static OMElement getRSTTemplate() throws Exception {
 OMFactory fac = OMAbstractFactory.getOMFactory();
 OMElement elem = fac.createOMElement(SP11Constants.REQUEST_SECURITY_TOKEN_TEMPLATE);
 TrustUtil.createTokenTypeElement(RahasConstants.VERSION_05_12, elem).setText(RahasConstants.TOK_TYPE_SAML_20);
 TrustUtil.createKeyTypeElement(RahasConstants.VERSION_05_12, elem, RahasConstants.KEY_TYPE_SYMM_KEY);
 TrustUtil.createKeySizeElement(RahasConstants.VERSION_05_12, elem, 256);

 return elem;
 }
}

Above listing depicts the complete version of the Client code. In order to make this work, you need to make some changes in the paths to repos, policies etc. Modify the repo, epr, servicePolicy and stsPolicy accordingly. I am explaining some of the important code segments of the above code for the sake of completion.

• After instantiating the STSClient object, we set its RSTTemplate. In this code, getRSTTemplate() method is used to create the RSTTemplate. The SAML version, key type and the key size are set to the RST(Request Security Token) inside this method. Following code snipped sets the SAML version, Key type and key length in RST.

 TrustUtil.createTokenTypeElement(RahasConstants.VERSION_05_12, elem).setText(RahasConstants.TOK_TYPE_SAML_20);
 TrustUtil.createKeyTypeElement(RahasConstants.VERSION_05_12, elem, RahasConstants.KEY_TYPE_SYMM_KEY);
 TrustUtil.createKeySizeElement(RahasConstants.VERSION_05_12, elem, 256);

• Then we set the RST action. In this scenario, we are requesting a token from the STS. So the corresponding trust action is ISSUE.

 String action = TrustUtil.getActionValue(RahasConstants.VERSION_05_02, RahasConstants.RST_ACTION_ISSUE);
 stsClient.setAction(action);

• Then the RST is sent to the STS. Here, we are passing the EPR of the RP service as a parameter. This is going to be checked against the set of trusted services we specified in the sts-configuration.

Token responseToken = stsClient.requestSecurityToken(loadPolicy(servicePolicy), "http://localhost:8081/axis2/services/STS", loadPolicy(stsPolicy), epr);

• After obtaining the token, we are storing it in the trust store and then sending it to the RP service.

You can download the source code, policy files and client site key store from here. Please note that you have to change the rampart-config parameters in both policy files to reflect your local settings.

In this sample, we are using a password callback handler to load the passwords of the private keys. In the client’s end, we are using the following password callback handler.

package org.wso2.sts;

import org.apache.ws.security.WSPasswordCallback;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
import java.io.IOException;

public class PWCBHandler  implements CallbackHandler{
    public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
         for (int i = 0; i < callbacks.length; i++) {
             WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i];
             String id = pwcb.getIdentifer();
             if("client".equals(id)) {
               pwcb.setPassword("apache");
             } else if("service".equals(id)) {
               pwcb.setPassword("apache");
            }
         }
   }
}

To get the client code up and running you need to add certain set of jars to your classpath. Most straight forward approach is adding the Axis2 ‘lib’ into your classpath. It contains all the jars required to compile and run this sample.

Following listing depicts the RST sent from Client to STS.

<wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
    <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.o383rg/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
            <wsa:Address>http://localhost:8081/axis2/services/sample05</wsa:Address>
        </wsa:EndpointReference>
    </wsp:AppliesTo>
    <wst:Lifetime>
        <wsu:Created>2009-10-20T13:15:51.739Z</wsu:Created>
        <wsu:Expires>2009-10-20T13:20:51.739Z</wsu:Expires>
    </wst:Lifetime>
    <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
    <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>
    <wst:KeySize>256</wst:KeySize>
    <wst:Entropy>
        <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce">
            g5WVRpUl7bKno8LYFC9JUGLpe1NZpkZ/
        </wst:BinarySecret>
    </wst:Entropy>
    <wst:ComputedKeyAlgorithm>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKeyAlgorithm>
</wst:RequestSecurityToken>

In this RST, RequestType is set to “http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue”. We have passed EPR of the RP service as a parameter when requesting the token. If you carefully observe  AppliesTo element, you will note the EPR we have passed has been set as the value of this element. Similarly the token type, key type and the key size are also appearing in the RST as we have set them in the RSTTemplate. The “Entopy” element is used pass a binary secret which is used to derive keys. I am not going into further details about key derivation is WS Trust. Plese refer to the WS Trust specification for further details.

Following is the resulting RSTR(Request Security Token Response) returned by the STS.

<wst:RequestSecurityTokenResponseCollection xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
    <wst:RequestSecurityTokenResponse>
        <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
        <wst:KeySize>256</wst:KeySize>
        <wst:RequestedAttachedReference>
            <wsse:SecurityTokenReference
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                <wsse:Reference URI="#urn:uuid:84DE938F17D3C897711256051606027"
                                ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
            </wsse:SecurityTokenReference>
        </wst:RequestedAttachedReference>
        <wst:RequestedUnattachedReference>
            <wsse:SecurityTokenReference
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                <wsse:Reference URI="urn:uuid:84DE938F17D3C897711256051606027"
                                ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
            </wsse:SecurityTokenReference>
        </wst:RequestedUnattachedReference>
        <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
            <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
                <wsa:Address>http://localhost:8081/axis2/services/sample05</wsa:Address>
            </wsa:EndpointReference>
        </wsp:AppliesTo>
        <wst:Lifetime>
            <wsu:Created>2009-10-20T15:13:26.138Z</wsu:Created>
            <wsu:Expires>2009-10-20T15:13:56.138Z</wsu:Expires>
        </wst:Lifetime>
        <wst:RequestedSecurityToken>
            <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                            ID="urn:uuid:84DE938F17D3C897711256051606027" IssueInstant="2009-10-20T15:13:26.002Z"
                            Version="2.0">
                <saml:Issuer>SAMPLE_STS</saml:Issuer>
                    ...
               </saml:Assertion>
        </wst:RequestedSecurityToken>
        <wst:RequestedProofToken>
            <wst:ComputedKey>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKey>
        </wst:RequestedProofToken>
        <wst:Entropy>
            <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce">
                r/JgXgGMFb4afwRQpggqky8q4TQm7pdXm8RQq9IgCzI=
            </wst:BinarySecret>
        </wst:Entropy>
    </wst:Reques66tSecurityTokenResponse>
</wst:RequestSecurityTokenResponseCollection>

SAML assertion contained in the RSTR is removed for brevity.

In this post, we have looked about the STS Configuration of Apache Rampart, how to obtain a SAML 2.0 Token, and how to use it to consume a web service. If you faced any issues, do not hesitate to post them here.

<wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
    <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.o383rg/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
            <wsa:Address>http://localhost:8081/axis2/services/sample05</wsa:Address>
        </wsa:EndpointReference>
    </wsp:AppliesTo>
    <wst:Lifetime>
        <wsu:Created>2009-10-20T13:15:51.739Z</wsu:Created>
        <wsu:Expires>2009-10-20T13:20:51.739Z</wsu:Expires>
    </wst:Lifetime>
    <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType>
    <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>
    <wst:KeySize>256</wst:KeySize>
    <wst:Entropy>
        <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce">
            g5WVRpUl7bKno8LYFC9JUGLpe1NZpkZ/
        </wst:BinarySecret>
    </wst:Entropy>
    <wst:ComputedKeyAlgorithm>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKeyAlgorithm>
</wst:RequestSecurityToken>

<wst:RequestSecurityTokenResponseCollection xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
    <wst:RequestSecurityTokenResponse>
        <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
        <wst:KeySize>256</wst:KeySize>
        <wst:RequestedAttachedReference>
            <wsse:SecurityTokenReference
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                <wsse:Reference URI="#urn:uuid:84DE938F17D3C897711256051606027"
                                ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
            </wsse:SecurityTokenReference>
        </wst:RequestedAttachedReference>
        <wst:RequestedUnattachedReference>
            <wsse:SecurityTokenReference
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                <wsse:Reference URI="urn:uuid:84DE938F17D3C897711256051606027"
                                ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"/>
            </wsse:SecurityTokenReference>
        </wst:RequestedUnattachedReference>
        <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
            <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
                <wsa:Address>http://localhost:8081/axis2/services/sample05</wsa:Address>
            </wsa:EndpointReference>
        </wsp:AppliesTo>
        <wst:Lifetime>
            <wsu:Created>2009-10-20T15:13:26.138Z</wsu:Created>
            <wsu:Expires>2009-10-20T15:13:56.138Z</wsu:Expires>
        </wst:Lifetime>
        <wst:RequestedSecurityToken>
            <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                            ID="urn:uuid:84DE938F17D3C897711256051606027" IssueInstant="2009-10-20T15:13:26.002Z"
                            Version="2.0">
                <saml:Issuer>SAMPLE_STS</saml:Issuer>
                    ...
               </saml:Assertion>
        </wst:RequestedSecurityToken>
        <wst:RequestedProofToken>
            <wst:ComputedKey>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKey>
        </wst:RequestedProofToken>
        <wst:Entropy>
            <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce">
                r/JgXgGMFb4afwRQpggqky8q4TQm7pdXm8RQq9IgCzI=
            </wst:BinarySecret>
        </wst:Entropy>
    </wst:Reques66tSecurityTokenResponse>
</wst:RequestSecurityTokenResponseCollection>

In this full-day interactive workshop, you will learn how to map specific business requirements to concrete SOA development patterns. If you’re ready to gain insight into real-world best practices for SOA, this session is for you.

Topics Covered

• ESBs and SOA

• SOA Security

• Mashups and Business Process Management for SOA

• SOA Governance

• SOA with C, C++, PHP and more

• SOA Enterprise Architecture Patterns

Date and Time

November 3 2009
9:00 am to 5:00 pm (Registration at 8:30 am)

Location

Network Meeting Center at Techmart
5201 Great America Parkway
Santa Clara, California 95054

Get registered today.

IS 2.0.1 release is available for download at [1].

This is based on revolutionary the WSO2 Carbon [2] framework, Middleware
a la carte’.

All the major features have been developed as pluggable Carbon components.

New Features
—————
1. SAML 2.0 Token Profile support
2. Passive STS
3. Equinox P2 based provisioning support
4. Improved Support for deploying on top of WebSphere, WebLogic, and
JBoss.
5. Various bug fixes and enhancements including architectural
improvements to Apache Axis2, Apache Rampart, Apache Sandesha2, WSO2
Carbon and other projects

Other Key Features
———————
1. Entitlement Engine with XACML 2.0 support.
2. Claim based Security Token Service.
3. Extension points for SAML assertion handling.
4. OpenID Provider
5. Information Card Provider

How to Run
——————
1. Extract the downloaded zip.
2. Go to the bin directory in the extracted folder.
3. Run the wso2server.sh or wso2server.bat as appropriate.
4. Point your browser to the URL https://localhost:9443/carbon
5. Use “admin”, “admin” as the user name and password.
6. If you need to start the OSGi console with the server use the
property -DosgiConsole when starting the server

Known issues
———————-
All the known issues have been filed here [3]. Please report any other
issues you find as JIRA entries.

Contact us
—————–
WSO2 Identity Server developers can be contacted via the mailing lists:
For Users: carbon-user@wso2.org
For Developers: carbon-dev@wso2.org

Alternatively, questions can also be raised in the Identity Server forum
at http://wso2.org/forum/308

Training
—————
WSO2 Inc. offers a variety of professional Training Programs, including
training on general Web services as well as WSO2 Identity Server,
Apache Axis2, Data Services and a number of other products. For
additional support information please refer to
http://wso2.com/training/course-catalog/

Support
————–
WSO2 Inc. offers a variety of development and production support
programs, ranging from Web-based support up through normal business
hours, to premium 24×7 phone support. For additional support information
please refer to http://wso2.com/support/

For more information on WSO2 Identity Server, visit the WSO2 Oxygen Tank[4].

Thank you for your interest in WSO2 Identity Server.

-The WSO2 Identity Server team

[1]: http://wso2.org/downloads/identity
[2]: http://wso2.org/projects/carbon
[3]: https://wso2.org/jira/browse/CARBON
[4]: http://wso2.org

There are two services called service 1 and service 2. Service 2 contains the actual business logic and Alice(service consumer) is interested about it. There is a Security Token Service(STS) which is trusted by both services.

1. Alice sends a RST to the STS authenticating herself to the STS. This is a normal RST.
2. STS returns a SAML Token to Alice in the RSTR. The subject of this SAML token is “Alice”. Let’s refer to this SAML token as token1.
3. Alice forwards the token1 with its soap request to service 1. Up to this message transfer, this is same as a usual trust brokering scenario.
4. Then service1 sends a RST to STS again authenticating itself to the STS. But this time the RST contains the token1 inside the “ActAs” element. (This ActAs element is introduced in the WS Trust 1.4.)
5. Now the STS issues a SAML token(referred to as token2). The subject of this token is “service1”. But it contains an attribute called “ActAs” with the value of “Alice”.
6. Then the service1 sends the token2 to “Service2”. Now the service2 understands that the original requester is “Alice” and “Service1” is acting as the original requester by processing the token2.
7. Then Service1 sends the response to Service2.
8. Finally, Service1 forwards the response to Alice.

Apache Rampart will be supporting WS-Trust 1.4 specification soon. So stay tuned..

This post is intended to provide a simplified explanation on how XML encryption works with SOAP messages as per the WS Security Specification.

WS Security Specification recommends to use symmetric keys for encryption. This is mainly due to the low performance factor of asymmetric key based encryption. Even if the asymmetric binding is used, it is advised to use symmetric keys for encryption. In such scenarios, the PKI is used to establish the symmetric keys. Initiator can come up with the symmetric and encrypt it using the public key of the recipient. Then the recipient can decrypt this key and find out the symmetric key which is used for encryption.

It is possible to encrypt the whole XML element or  just the content of it. WS Security Specification enforces not to encrypt <S11:Header>, <S12:Header>, <S11:Envelope>, <S12:Envelope>,or <S11:Body>, <S12:Body> elements. But encrypting the sub elements of those elements are allowed.

If a particular element or content of it is supposed to be encrypted, then that element should be replaced by the <xenc:EncryptedData> element which is the result of encrypting the original element.

Ex :

<xenc:EncryptedData Id="EncDataId-3" Type="http://www.w3.org/2001/04/xmlenc#Content">...</xenc:EncryptedData>

Symmetric keys used for the encryption operations should be embedded inside <xenc:EncryptedKey> elements. Each <xenc:EncryptedKey> element should contain a <ds:KeyInfo> element that contains information about the key used to encrypt the symmetric key. Then there can be a <xenc:ReferenceList> which is the manifest of the elements which are encrypted. If a <xenc:ReferenceList> element is appearing inside a <xenc:EncryptedKey> element, it implies that the symmetric key resulted by decrypting the cipher value of the <xenc:EncryptedKey> element should be used decrypt the elements specified in that refernce list. <xenc:ReferenceList> is comprised of a list of <xenc:DataReference> elements which contains refernces to the elements which are encrypted using this key. If we put this in a simplified manner, <xenc:ReferenceList> inside a <xenc:EncryptedKey> element refers to all the <xenc:EncryptedData> elements which are encrypted using the symmetric key contained in that  <xenc:EncryptedKey> element. Each <xenc:EncryptedData> element should be referred using <xenc:DataReference> element.

Ex :

          <xenc:EncryptedKey Id="EncKeyId-E296581B23458CA12512507910022225">
                <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
                <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                    <wsse:SecurityTokenReference>
                        <wsse:KeyIdentifier
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                                ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">
                            HYL371NzoOs2+IA24VDkBGcUFQM=
                        </wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
                <xenc:CipherData>
                    <xenc:CipherValue>
                        H9l+f1lqTvi4W3vaHwXMhhdfOT8t2t75fzgCkUvjX7ae9FLMEm7/hoQCEurJE4SOmPRXUvLV3MSI21Fcr3HW2OFc1SEpAZQwxma03/iG0jlSyAOOO/j9jitTnmvhtMGI9HShrM0cP77U0GDBTIoXqMSOrzMKbSQ8iz7wl5dG+TY=
                    </xenc:CipherValue>
                </xenc:CipherData>
                <xenc:ReferenceList>
                    <xenc:DataReference URI="#EncDataId-3"/>
                </xenc:ReferenceList>
          </xenc:EncryptedKey>

Lets come back to the <xenc:EncryptedData> element. Earlier we said that all the elements which should be encrypted must be replaced by a <xenc:EncryptedData> elements. This element might contain a <ds:KeyInfo> element which points to another <ds:KeyInfo> element or an attached security token. But it is not mandatory to have such <ds:KeyInfo> element, if that <xenc:EncryptedData> element is listed in a <xenc:ReferenceList> of a particuar <xenc:EncryptedKey>. It should contain a </xenc:CipherData> element, which contains the cipher data.

Ex :

      <xenc:EncryptedData Id="EncDataId-3" Type="http://www.w3.org/2001/04/xmlenc#Content">
            <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <wsse:SecurityTokenReference
                        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                    <wsse:Reference URI="#EncKeyId-E296581B23458CA12512507910022225"/>
                </wsse:SecurityTokenReference>
            </ds:KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue>HTnMneoskQeLew99eIqCLh+8kUAvKozGjsLMfBN8Ji2QDx64Rl53vKqXYybDQeGidWHn9L7OFSEW
                    6kWuSsDqB+AWQezNgoACcxrNfn7vGwQidD3Kl6aviSaFALzJJkphk29Cip7vSOFmxJn3qIaA82AD
                    rrnPYT57uyPh03XELwrv1Wret3q1uNZ0pnjk6xjYjsQzkAgADUeE/MfWSMdjvpZ6eQ4wwTOmemeh
                    HtVLEdIsKoCyXRBMC9Etiu3KoymArNWRAMgQHvSzBmGxuWCALOHYru8OJpmetZacz5KVqWHifRhP
                    wXFsWOQF3zfBQhJmf4fRiAXkeJ4ZXn3BjT4dz/BVoDaHJFEwK5KY9GRtg0U7Eu3l5k6RNM3ds56N
                    PGP/DhvKJfcFCh4qKVfbWFDVLdeqcRzrHXWuiHTu6BoiwJgzFoQ8vjP6Bw==
                </xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>

Having said about the optional <ds:KeyInfo> element inside a <xenc:EncryptedData> element, now it is possible to take the <xenc:ReferenceList> element out of the <xenc:EncryptedKey> element if required. In such scenarios, <xenc:EncryptedData> elements should contain the <ds:KeyInfo> elements pointing to the keys that are used for the encryption. With this option, it is possible to use multiple keys for encrypting the elements in the same SOAP message.

So lets bring all the bits and pieces together. Following listing depicts a SOAP message with an encrypted soap body.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
        <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                       soapenv:mustUnderstand="1">
            <xenc:EncryptedKey Id="EncKeyId-E296581B23458CA12512507910022225">
                <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
                <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                    <wsse:SecurityTokenReference>
                        <wsse:KeyIdentifier
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                                ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">
                            HYL371NzoOs2+IA24VDkBGcUFQM=
                        </wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
                <xenc:CipherData>
                    <xenc:CipherValue>
                        H9l+f1lqTvi4W3vaHwXMhhdfOT8t2t75fzgCkUvjX7ae9FLMEm7/hoQCEurJE4SOmPRXUvLV3MSI21Fcr3HW2OFc1SEpAZQwxma03/iG0jlSyAOOO/j9jitTnmvhtMGI9HShrM0cP77U0GDBTIoXqMSOrzMKbSQ8iz7wl5dG+TY=
                    </xenc:CipherValue>
                </xenc:CipherData>
                <xenc:ReferenceList>
                    <xenc:DataReference URI="#EncDataId-3"/>
                </xenc:ReferenceList>
            </xenc:EncryptedKey>
        </wsse:Security>
        <wsa:To>http://localhost:8081/axis2/services/sample03</wsa:To>
        <wsa:MessageID>urn:uuid:EE5C34B1DCEF6DBA991250791000372</wsa:MessageID>
        <wsa:Action>urn:echo</wsa:Action>
    </soapenv:Header>
    <soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
                  wsu:Id="Id-14900151">
        <xenc:EncryptedData Id="EncDataId-3" Type="http://www.w3.org/2001/04/xmlenc#Content">
            <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <wsse:SecurityTokenReference
                        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                    <wsse:Reference URI="#EncKeyId-E296581B23458CA12512507910022225"/>
                </wsse:SecurityTokenReference>
            </ds:KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue>HTnMneoskQeLew99eIqCLh+8kUAvKozGjsLMfBN8Ji2QDx64Rl53vKqXYybDQeGidWHn9L7OFSEW
                    6kWuSsDqB+AWQezNgoACcxrNfn7vGwQidD3Kl6aviSaFALzJJkphk29Cip7vSOFmxJn3qIaA82AD
                    rrnPYT57uyPh03XELwrv1Wret3q1uNZ0pnjk6xjYjsQzkAgADUeE/MfWSMdjvpZ6eQ4wwTOmemeh
                    HtVLEdIsKoCyXRBMC9Etiu3KoymArNWRAMgQHvSzBmGxuWCALOHYru8OJpmetZacz5KVqWHifRhP
                    wXFsWOQF3zfBQhJmf4fRiAXkeJ4ZXn3BjT4dz/BVoDaHJFEwK5KY9GRtg0U7Eu3l5k6RNM3ds56N
                    PGP/DhvKJfcFCh4qKVfbWFDVLdeqcRzrHXWuiHTu6BoiwJgzFoQ8vjP6Bw==
                </xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </soapenv:Body>
</soapenv:Envelope>

An asymmetric key is used for encrption. <xenc:EncryptedKey> element contains a <ds:KeyInfo> element which can be used by the recipient to locate the correct private key from his keystore to decrypt the symmetric key. <wsse:SecurityTokenReference> element inside that <ds:KeyInfo> element specifies a ThumbprintSHA1 value that can be used as a key identifier. Then it contains a <xenc:CipherData> which contains the cipher text of the symmetric key. Decrypting this cipher text using the private key of the recipient with result with the symmetric key.

Then it has the <xenc:ReferenceList> with a single <xenc:DataReference> element. That <xenc:DataReference> element refers to an element using the URI fragment #EncDataId-3. If you carefully observe, you will note that, this URI fragment is the ID of the <xenc:EncryptedData> which is the child element of the soap body. That <xenc:EncryptedData> element contains a <ds:KeyInfo> element which points to the <xenc:EncryptedKey> element mentioned above using a SecurityToken Reference. <xenc:CipherValue> contains the encrypted content of the soap body, which should be decrypted using the symmetric key.

I did not discussed about encrypting SOAP headers, to keep this note short as much as possible.

Refer to WS Security Specification for a comprehensive description about the SOAP message encryption.

WS Security Policy Specification defines three security binding assertions, namely Transport Binding, Symmetric Binding and Asymmetric Binding. All these bindings are ideal for different use cases and only the Asymmetric Binding is discussed in detail in this post.

What is Assymetric Binding ?

According to the WS Security Specification, “The AsymmetricBinding assertion is used in scenarios in which message protection is provided by means defined in WSS: SOAP Message Security using asymmetric key (Public Key) technology”. If we put this in a simplified manner, Asymmetric Binding can be used when both parties possess key pairs. For example, if both the parties possess X.509 certificates, then it is possible to use asymmetric binding.

In asymmetric binding, message encryption and signing takes place using the Public Key Infrastructure(PKI), i.e. sender encrypts messages using the public key of the recipient and sign the messages using his private key. Then the recipient can decrypt the received messages using his private key and verify the signature of the message using the public key of the sender. This way, the confidentiality, integrity and the non-repudiation properties of the message exchanges can be assured.

Following diagram explains how asymmetric binding works.

Asymmetric Binding Policy Assertion

Following is a sample Asymmetric Binding policy assertion.

<sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
    <wsp:Policy>
       <sp:InitiatorToken>
          <wsp:Policy>
             <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                 <wsp:Policy>
                     <sp:RequireThumbprintReference/>
                     <sp:WssX509V3Token10/>
                 </wsp:Policy>
            </sp:X509Token>
          </wsp:Policy>
       </sp:InitiatorToken>
       <sp:RecipientToken>
          <wsp:Policy>
             <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
                 <wsp:Policy>
                     <sp:RequireThumbprintReference/>
                     <sp:WssX509V3Token10/>
                 </wsp:Policy>
            </sp:X509Token>
        </wsp:Policy>
       </sp:RecipientToken>
       <sp:AlgorithmSuite>
          <wsp:Policy>
             <sp:TripleDesRsa15/>
          </wsp:Policy>
       </sp:AlgorithmSuite>
       <sp:Layout>
          <wsp:Policy>
             <sp:Strict/>
          </wsp:Policy>
       </sp:Layout>
       <sp:IncludeTimestamp/>
       <sp:OnlySignEntireHeadersAndBody/>
     </wsp:Policy>
 </sp:AsymmetricBinding>

In asymmetric binding scenario, keys used for signature and encrypting should be clearly specified. This is facilitated in the Assymetric Binding assertion itself. An assymetric binding usually contains two main elements, InitiatorToken and RecipientToken. These tokens provides room for specifying the tokens used in the signing/encrypting operations by the sender(initiator) and recipient respectively. According to the specification, each of these two elements should contain tokens used for signing and encrypting. In this policy, X.509 certificate is used for signing/encrypting at each end. This is specified using a X.509 supporting token.

In addition to those two elements, other properties like Algorithmic Suite, IncludeTimeStamp can also be specified in the Asymmetric Binding element similar to other security binding assertions.

Rampart Configuration

Although we have specified that we are using a X.509 certificates for signing and encrypting in the policy, there should be a way to point to those certificates from both ends. Now the Rampart Configuration element comes into play. Following is the Rampart-Config of the client side. Server side should also contain a RampartConfig element which is almost similar to this.

<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
    <ramp:userCertAlias>client</ramp:userCertAlias>
    <ramp:encryptionUser>service</ramp:encryptionUser>
    <ramp:passwordCallbackClass>org.apache.rampart.asymm.PWCBHandler</ramp:passwordCallbackClass>

    <ramp:signatureCrypto>
       <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.file">
            /path/to/client.jks</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password">apache</ramp:property>
       </ramp:crypto>
    </ramp:signatureCrypto>
</ramp:RampartConfig>

Lets go through each of these elements.

<ramp:userCertAlias> – alias of the key used for signing.

<ramp:encryptionUser> – used to identify the key that is used to encrypt, i.e. alias of the recipient’s certificate.

<ramp:passwordCallbackClass> – used to get the password of the private key that is used for signing.

<ramp:signatureCrypto> – information about the key store that contains the necessary keys. Here, we are providing the keystore type, location and keystore password. This element only defines the keystore that contains the keys used for signing. Similarly there can be a another element called encryptionCypto containg keystore information used for encryption. In Rampart, if this element is not specified, properties defined in ramp:signatureCrypto element is used for encryption operations.

Policy

Following listing is the policy I have used in this sample. Since the Asymmetric Binding assertion is provided before I have removed that assertion from the policy for the brevity.

?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy wsu:Id="SigOnly"  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
          xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <wsp:ExactlyOne>
      <wsp:All>
         <sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
               ....
         </sp:AsymmetricBinding>
         <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
            <wsp:Policy>
                <sp:MustSupportRefKeyIdentifier/>
                <sp:MustSupportRefIssuerSerial/>
            </wsp:Policy>
         </sp:Wss10>
         <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
            <sp:Body/>
         </sp:SignedParts>
       </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

The body of the soap message should be singed according to the policy.

Please note that the corresponding RampartConfig elements should also be appended to the policy. The complete policy.xml and the services.xml files can be found in the resources.

Service

I am using a simple echo service in this sample. The service class looks similar to this.

public class SimpleService {
  public String echo(String arg) {
      return arg;
  }
}

This service file can be found in the resources.

Client

package org.apache.rampart.asymm;

import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axiom.om.impl.builder.StAXOMBuilder;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.neethi.Policy;
import org.apache.neethi.PolicyEngine;
import org.apache.rampart.RampartMessageData;

public class AsymmBindingClient {
     public static void main(String[] args) throws Exception {

       String repo = "/path/to/repo";
       String EPR = "http://localhost:8080/axis2/services/sample02";
       String policyPath = "/path/to/policy.xml";

       // instantiating a ConfigurationContext object pointing to a Axis2 repository.
       ConfigurationContext ctx = ConfigurationContextFactory.createConfigurationContextFromFileSystem(repo, null);

       ServiceClient client = new ServiceClient(ctx, null);

       //Setting the properties to the service client.
       Options options = new Options();
       options.setAction("urn:echo");
       options.setTo(new EndpointReference(EPR));
       options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, loadPolicy(policyPath));
       client.setOptions(options);

       // engage modules
       client.engageModule("addressing");
       client.engageModule("rampart");

       //invoke the web service
       OMElement response = client.sendReceive(getPayload("Hello world"));

       System.out.println(response);

   }

    private static Policy loadPolicy(String xmlPath) throws Exception {
       StAXOMBuilder builder = new StAXOMBuilder(xmlPath);
       return PolicyEngine.getPolicy(builder.getDocumentElement());
   }

   private static OMElement getPayload(String value) {
      OMFactory factory = OMAbstractFactory.getOMFactory();
      OMNamespace ns = factory.createOMNamespace("http://sample02.policy.samples.rampart.apache.org", "ns1");
      OMElement elem = factory.createOMElement("echo", ns);
      OMElement childElem = factory.createOMElement("param0", ns);
      childElem.setText(value);
      elem.addChild(childElem);

      return elem;
   }
}

Since we have used policy based configuration, most of the rampart configuration is done at the policy. So this class is simple. If you have already gone through my previous post about using username token + HTTPS to secure a web service, it is easy to understand this code.

Request and Response

You can find both the request and response generated in this service invocation in the resources. You will see that the body of the SOAP message is signed using the private key of the sender. So the recipient can verify that signature using the ppublic key of the sender.

Image Courtesy : Understanding WS – Security Policy Language by Nandana Mihindukulasooriya.

]]> http://thilinamb.wordpress.com/2009/08/19/ws-security-policy-assymetric-binding-explained/feed/ 0 thilinamb asymmetric http://thilinamb.wordpress.com/2009/08/18/securing-a-web-service-with-username-token-https-with-apache-rampart/ http://thilinamb.wordpress.com/2009/08/18/securing-a-web-service-with-username-token-https-with-apache-rampart/#comments Tue, 18 Aug 2009 17:36:04 +0000 thilinamb http://thilinamb.wordpress.com/?p=200 ]]> This post has been moved to : http://blog.thilinamb.com/2009/08/securing-web-service-with-username.html