Skip to content

Webservice Security – WS-Trust and WS-SecureConversation an overview

03-Feb-12

Webservices

“A Web Service is a system designed to support interoperable communication from machine to machine over a network. It includes an interface described in a machine-processable format (WSDL), and is typically conveyed using HTTP with XML serialization.”
Webservices exist in a wide range of architecture, technologies and software design. They provide an interaction mechanism between Business to Business applications. Webservices rely on SOAP Protocol for the interaction between the B2B applications. SOAP is and XML Based protocol that uses HTTP as its base transport protocol. Following is an example of a SOAP Request and SOAP Response

 

REQUEST

 

POST /SecureHelloWorldService/SecureHelloWorldService

HTTP/1.1 User-Agent: BEA WebLogic Server 10.3.0.0

Content-Type: text/xml; charset=utf-8 SOAPAction: “”

Host: 127.0.0.1:7000

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive Content-Length: 187

 

<env:Envelope xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”>

<env:Header />

<env:Body>

<m:sayHello xmlns:m=”http://www.bea.com”>

<m:s>World</m:s>

</m:sayHello>

</env:Body>

</env:Envelope>

 

RESPONSE

 

HTTP/1.1 200 OK Date: Tue, 24 Jan 2012 06:15:42 GMT

Transfer-Encoding: chunked

Content-Type: text/xml; charset=utf-8

SOAPAction: “” X-Powered-By: Servlet/2.5 JSP/2.1

 

<env:Envelope

xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”>

<env:Header />

<env:Body>

<m:sayHelloResponse xmlns:m=”http://www.bea.com”>

<m:return>Hello World</m:return>

</m:sayHelloResponse>

</env:Body>

</env:Envelope>

 

Webservices Security

For a secure environment data exchange cannot happen in clear text as sensitive information might be exchanged. Also securing the communication channel for all communication is an overhead and might not be acceptable in all scenarios. Hence many specifications exist which allows to secure the data exchanged. One such framework is WS-Policy which defines how secure messages can be exchanged. To demonstrate this I have secured the above Webservice using standard policies and captured the SOAP Request and SOAP Response

 

@Policies({    @Policy(uri=”policy:Auth.xml”, direction=Policy.Direction.inbound),    @Policy(uri=”policy:Sign.xml”),    @Policy(uri=”policy:Encrypt.xml”)})

 

The message body is encrypted

<env:Body wsu:Id=”Body_FE10KgY262Y31ZRm” xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>

<ns1:EncryptedData Id=”3ZpXu9BlqgQNKF4s” Type=”http://www.w3.org/2001/04/xmlenc#Content” MimeType=”text/xml” Encoding=”UTF-8″ xmlns:ns1=”http://www.w3.org/2001/04/xmlenc#”> <ns1:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#tripledes-cbc” /> <ns1:CipherData> <ns1:CipherValue> T7MoCfhyDwXRjLrpRhZ62es3qK2jhTbY2ReS1ZSWhRaBidi8DwW5EbzNQKgudtPa8m7zxkW/ljebMV5dSvIZrJC1o+6peC111iFgPC4jMyA= </ns1:CipherValue>

</ns1:CipherData>

</ns1:EncryptedData>

</env:Body>

 

In addition to this, security tokens need to be passed for authentication and authorization purpose.

Username Password Token

<wsse:UsernameToken wsu:Id=”unt_CQbnapvDgXSDnTtZ” xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”> <wsse:Username>weblogic</wsse:Username>

<wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”> weblogic </wsse:Password>

</wsse:UsernameToken>

 

Binary Security Token

<wsse:BinarySecurityToken wsu:Id=”bst_MIWyV2RKFBlLh9AT”xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”ValueType=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3″EncodingType=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary”>MIICYTCCAgugAwIBAgIQsAtcv4jhs9Rpsu6m…..

…………………………………………………………………………………xuT69jAN

BgkqhkiG9w0BAQQFADB5MQswCQYDVQQGEwJVUzEQM

/wsse:BinarySecurityToken>

 

Following is the lists of supported tokens that can be used for authentication and authorization purposes

Lists of tokens (Table 1)

Table 1

Token Type Description
User Name Token-Plain Carries basic information (username and a clear text password or shared secret) for purposes of authenticating the user identity to the WSP. Communication is done in plain text so SSL over HTTPS transport must be used to protect the credentials.
Kerberos Token Carries basic information (username and, optionally, a password or shared secret), in a Kerberos token, for purposes of authenticating the user identity to the WSP.
X.509 Token Contains an X.509 formatted certificate for authentication using credentials created with a public key infrastructure (PKI). In this case, the WSC and WSP must trust each other’s public keys or share a common, trusted certificate authority.
SAML-Holder-Of-Key Token Uses the SAML holder-of-key confirmation method whereby the WSC supplies a SAML assertion with public key information as the means for authenticating the requester to the web service provider. A second signature binds the assertion to the SOAP payload. Can use either SAML v1.x or SAML v2.
SAML-Sender Vouches Token Uses the SAML sender-vouches confirmation method whereby the WSC adds a SAML assertion and a digital signature to a SOAP header. A sender certificate or public key is also provided with the signature. Can use either SAML v1.x or SAML v2.

 

Key Exchange using WS-Trust

In the model above it’s the responsibility of the server to validate the tokens, signatures and perform authentication and authorization. This again can be an overhead, especially if the numbers of clients are very high. Also if the client is not known to the Service, it becomes difficult to establish a trust with the client. To address this situation WS-Trust standard has been adopted.  In this model, the responsibility of establishing the trust has been assigned to a third party. Clients request for a Security Token from a Secure Token Server (STS). Once they get the token, they present the token to the Service. The exchange mechanism and standard format of the token has been provided in WS-Trust specification.  In my test, I used opensso (an open source STS Server) and captured the request-response interaction as depicted in Figure below.

 



1)Client requests for a Security token to a Secure Token Server

<soap:Envelope  xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing”  xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility”  xmlns:wsse=”http://schemas.xmlsoap.org/ws/2002/12/secext”  xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>

<soap:Header>      <wsa:To>http://demo</wsa:To>

<wsse:Security soap:mustUnderstand=”1″>  ….      </wsse:Security>    </soap:Header>    <soap:Body wsu:Id=”Id-d7fceab4-62ed-45fb-bc09-69310ff1712e”>      <wsse:RequestSecurityToken>        <wsse:TokenType>wsse:SecurityContextToken</wsse:TokenType>        <wsse:RequestType>wsse:ReqIssue</wsse:RequestType>        <wsp:AppliesTo xmlns:wsp=”http://schemas.xmlsoap.org/ws/2002/12/policy”>          <wsa:EndpointReference>            <wsa:Address>http://localhost:7001//SecureHelloWorldService/SecureHelloWorldService</wsa:Address>          </wsa:EndpointReference>

</wsp:AppliesTo>

</wsse:RequestSecurityToken>    </soap:Body>

</soap:Envelope>

2)Secure Token Server provides the token to the Client.

<soap:Envelope xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing”  xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility”  xmlns:wsse=”http://schemas.xmlsoap.org/ws/2002/12/secext”  xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>

<soap:Header>      <wsse:Security soap:mustUnderstand=”1″> ….

</wsse:Security>

</soap:Header>    <soap:Body wsu:Id=”Id-aa53632b-2211-46c8-451-4234b12ecf834″>

<xenc:EncryptedData xmlns:xenc=”http://www.w3.org/2001/04/xmlenc#”>        <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#tripledes-cbc” />        <xenc:CipherData>          <xenc:CipherValue>…

</xenc:CipherValue>

</xenc:CipherData>

</xenc:EncryptedData>

</soap:Body>  </soap:Envelope>

3)Using the token, the service is invoked.

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”  xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”  xmlns:xsd=”http://www.w3.org/2001/XMLSchema”  xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing”  xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility”  xmlns:wsse=”http://schemas.xmlsoap.org/ws/2002/12/secext”>

<soap:Header>      <wsa:To>http://quoteservice</wsa:To>

<wsse:Security soap:mustUnderstand=”1″> ….      </wsse:Security>

</soap:Header>    <soap:Body wsu:Id=”Id-aa53632b-2211-46c8-451-4234b12ecf834″>

<xenc:EncryptedData xmlns:xenc=”http://www.w3.org/2001/04/xmlenc#”> …

</xenc:EncryptedData>    </soap:Body>

</soap:Envelope>

 

4)Response from the service

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”  xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”  xmlns:xsd=”http://www.w3.org/2001/XMLSchema”  xmlns:wsa=”http://schemas.xmlsoap.org/ws/2004/08/addressing”  xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility”>    <soap:Header>    </soap:Header>    <soap:Body>       <m:sayHelloResponse xmlns:m=”http://www.bea.com”>

<m:return>Hello World</m:return>       </m:sayHelloResponse>

</soap:Body>

</soap:Envelope>

 

References

1) Webservices Vulnerabilities, Security Compass Inc 2007
2) WS Trust Specification

http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf

3) WS Security Specification

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

4) Open SSO STS Solution

http://en.wikipedia.org/wiki/OpenSSO

http://www.oracle.com/technetwork/testcontent/opensso-091890.html

Converting certificate formats

25-Jan-12

Converting Certificate from JKS to P12 Format

keytool -importkeystore -srckeystore Fabrizio.jks -destkeystore Fabrizio.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass weblogic1 -deststorepass weblogic1 -srcalias {4d390f81-7f7a-4a0a-ae76-9a5ea5ba567f} -destalias {4d390f81-7f7a-4a0a-ae76-9a5ea5ba567f} -srckeypass weblogic1 -destkeypass weblogic1

Converting certificate from PFX to JKS Format

java -classpath ./jetty-6.1.1.jar org.mortbay.jetty.security.PKCS12Import Fabrizio.pfx Fabrizio.jks

Converting certificate from P12 to PFX Format

1. Import the certificate in the browser using certificate import wiward by double clicking on the p12 certificate.
2. Go to Internet Options > Content > Certificates > Personal
3. Choose your certificate and click export.
4. Select Yes Export the Private Key
5. Select Personal Information Exchange Format and provide the password.
6. Store the file as .pfx.

Thread Dumps

04-Oct-11

There could be scenarios like Server Hang, Crashes, Performance delays where you might need to capture Thread Dumps for further analysis.

Thread dumps provide a snapshot of the current active threads. It provides the stack trace of all the java threads in the JVM.

There are different ways to capture thread dumps; some are based on the operating systems.

On Windows:

  1. Go to the server standard output and press a Control + Break and copy the thread dump onto a file

On UNIX/ Linux

Find the process id for your server

  1. Ps –ef  | grep java
  2. Kill -3 <pid>

 

WebLogic utilities to capture thread dumps

1. webLogic.Admin utility

a. Open a command prompt , set the classpath running <DOMAIN_HOME>/bin/setDomain.env

b. Execute the below command

java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic1 THREAD_DUMP

Note: Thread Dump will be printed to the servers standard out (by default, the shell in which the server is running).

2. Using Admin Console

a. Log into the Admin Console , click on the server

b. Click onto the Server  –> Monitoring  –> Threads

c. Click on the Dump Thread Stack

 

 

3. Using WLST (WebLogic Scripting Tool)

a. Save and execute  the below snippet as ThreadDump.py

************************************

connect(‘weblogic’,'weblogic1′,’t3://localhost:7001′)

cd(‘Servers’)

cd(‘AdminServer’)

threadDump()

disconnect()

exit()

************************************

Note: The thread dumps get stored in the location from where you run the WLST script

 

If your Server is running as windows service, then follow the below steps

1. Open a command prompt and execute the below command

WL_HOME\bin\beasvc -dump -svcname:service-name

There are other tools that can be used to capture thread dumps for example jrcmd (for JRockit) ,Samurai etc.

NOTE: It is recommended to capture a set of 6-7 thread dumps at an interval 8-10 seconds to find a pattern in the thread execution.

Cheers,

Wonders Team