Tuesday Feb 24, 2009

WS-SecureConversation, Improve performance of your Webservice

Public key cryptography

WS-Security make extensive use of the public key cryptography. Public key cryptography(asymmetric key) is computationally more expensive than symmetric key cryptographic, see the following link for more  info, so the solution is to make use of combination of asymmetric and symmetric key cryptography.  


While message authentication is useful for simple or one-way messages, parties that wish to exchange multiple messages typically establish a secure security context in which to exchange multiple messages. A security context is shared among the communicating parties for the lifetime of a communications session. Once the context and secret have been established (authenticated), Derived Keys can be used for signing and encryption of the messages. Some of features of ws-secureconversation are

  • similar to SSL

  • create a security context

  • message processing is  much faster at both client and webservice endpoint

  • transparent to the user 


 Esstablishing Security Context

A security context needs to be created and shared by the communicating parties before being used. This is done by creatring a Security Context Token(SCT). The specification defines three different ways of establishing a security context among the parties of a secure communication.

  • SCT created by a  STS(security token service)

  • SCT created by one of the communicating parties and propagated with a message

  • SCT created through negotiation/exchanges

WS-Secure Conversation is built on top of two other web services specifications, they are WS-Security and WS-Trust. In metro/wsit each web service enabled for WS-SecureConversation has an associated STS that is used to issue and manage security contexts

To request a Security Context Token(SCT) , an RequestSecurityToken(RST) is sent to the webservice endpoint which is setup using secure conversation , the request is transparently routed to the trust service which responds with a RequestSecurityTokenResponse , the response is send back to the client, Note the sample below also show DerivedKeyToken, we will talk about derived keys in a moment.

 Sample SecurityContextToken and DerivedKeyToken



                xmlns:ns16="http://www.w3.org/2003/05/soap-envelope" wsu:Id="_3">
    <wsse:SecurityTokenReference wsu:Id="_5002">
        <wsse:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" URI="#uuid-4063ae9b-fe66-4e09-a5fb-8fda903f34d8" />


note the element /wsc:SecurityContextToken/wsc:Identifier This required element identifies the security context using an absolute URI. Each security context URI MUST be unique to both the sender and recipient. It is RECOMMENDED that the value be globally unique in time and space 

Derived Keys  

A security context token implies or contains a shared secret. This secret MAY be used for signing and/or encrypting messages, but it is RECOMMENDED that derived keys be used for signing and encrypting messages associated only with the security context

Using a common secret, parties may define different key derivations to use. For example, four keys may be derived so that two parties can sign and encrypt using separate keys. In order to keep the keys fresh (prevent providing too much data for analysis), subsequent derivations may be used 

 how the derived keys are used


How Keys are derived? 

A subset of the mechanism defined for TLS in RFC 2246. Specifically, P_SHA-1 function is used to generate a sequence of bytes that can be used to generate security keys. the algorithm is refered to as:


This function is used with three values – secret, label, and seed. The secret is the shared secret that is exchanged (note that if two secrets were securely exchanged, possible as part of an initial exchange, they are concatenated in the order they were sent/received).Secrets are processed as octets representing their binary value (value prior to encoding). The label is the concatenation of the client's label and the service's label. These labels can be discovered in each party's policy (or specifically within a <wsc:DerivedKeyToken> token). Labels are processed as UTF-8 encoded octets. If either isn't specified in the policy, then a default value of "WS-SecureConversation" (represented as UTF-8 octets) is used. The seed is the concatenation of nonce values (if multiple were exchanged) that were exchanged (initiator + receiver). The nonce is processed as a binary octet sequence (the value prior to base64 encoding). The nonce seed is required, and MUST be generated by one or more of the communicating parties.The P_SHA-1 function has two parameters – secret and value. The label and the seed is concatenated to create the value. That is:

P_SHA1 (secret, label + seed)

Syntax For Derived Keys

<DerivedKeyToken wsu:Id="..." Algorithm="...">


for more details for each of the element see the specification

How To Configure in Composite Application/WSIT editor

GlasfishESB , metro support the following security profiles, chose one of the security profile in the CASA editor and then configure for secure-conversation

  • Username Authentication with Symmetric Keys

  • Mutual Certificates Security

  • Transport Security (SSL)

  • Message Authentication over SSL

  • SAML Authorization over SSL

  • Endorsing Certificate

  • SAML Sender Vouches with Certificates

  • SAML Holder of Key

  • STS Issued Token

  • STS Issued Token with Service Certificate

  • STS Issued Endorsing Token

how to configure

Friday Jul 11, 2008

Security in open-esb

Basic Authentication, this can be based on 

1. Glassfish security realm
2. Sun Java Access Manager
3. WssTokenCompare

 The following steps describes the basic authentication process

  • The client sends a request to the Web service, sending the  credentials as part of the http authorization header , base64 encoded.
  • The Web service validates the credentials against the glassfish/access-manager /WssTokenCompare.
  • The Web service returns a response to the client.

 For more information see basic authentication

Basic Authentication and Authorization

1. this support is only available while using Sun Java System Access Manager while doing basic authentication for more detail see

Brokered Authentication  

The brokered authentication has the following steps

  • The client submits an authentication request
  • The authentication broker validate the authentication credentials , The authentication broker responds to the client if authentication is successful and issues a security token. The client can use the security token to authenticate with the service.
  • A request message containing the security token is sent to the service.
  • The service authenticates the request by validating the security token and sent the response

In open-esb this is achieved using wsit , and the most common security mechanism used in this regard are

  •  X509 Security token
  • Security Token Service

Fore more details see the following examples




« April 2014