Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

  def Softwaremaker() :
         return "William Tay", "<Challenging Conventions />"

  knownType_Serialize, about = Softwaremaker()

 Friday, October 24, 2008

Ahhh ... it has been a while, hasnt it ?

My life is just torn between working with bits of 2, beats of 4 and nucleotides of 4. But while challenging, it has been really fun. As spoken to a friend today, my passions in life seeks out to expand the comfort boundaries of gray matter, which we called the mind and to constantly challenge and stimulate the brain to learn and absorb new things that one would never think of learning if one boxed themself in a virtual space, which techies like me would call "typecast".

One example that I highlighted to my friend today, which I respectfully pointed out to them that he falls under, is when he said: "But we tech people are not good at talking to people and engaging them in meaningful conversations ..."

Typecast alert !

I ended up talking with him (not to him) for a good 20 minutes and told him we just had a meaningful conversation and that he could hold one really well. I told him that he himself set up this virtual boundary to box himself in. No one did and that he could easily remove this barrier and elevate himself to do and more importantly, to learn new things and behaviors. Instead of having new curiousities about old things, have new questions, passions and interests towards new things.

Anyways, I wont be talking about my new-found passions here but I will be briefly touching on a topic that many people knew I have passions for (and I still do) - and that is the innards and the plumbings of software technologies.

I came across types of this type of questions a lot in emails, forum questions and usergroup events:

openquotes.png I have this WSDL file that looks something like this:

<?xml version='1.0' encoding='UTF-8'?>

<definitions name="someCustomer" targetNamespace="urn:someCustomer" xmlns:typens="urn:someCustomer" xmlns:xsd="" xmlns:soap="" xmlns:soapenc="" xmlns:wsdl="" xmlns="">
      <message name="add_someCustomer">
            <part name="resId" type="xsd:string"/>
            <part name="cPortable" type="xsd:string"/>
      <message name="add_someCustomerResponse">
            <part name="add_someCustomerReturn" type="xsd:string"/>
      <portType name="someCustomerPortType">
            <operation name="add_someCustomer">
                  <input message="typens:add_someCustomer"/>
                  <output message="typens:add_someCustomerResponse"/>
      <binding name="someCustomerBinding" type="typens:someCustomerPortType">
            <soap:binding style="rpc" transport=""/>
            <operation name="add_someCustomer">
                  <soap:operation soapAction="urn:someCustomerAction"/>
                        <soap:body namespace="urn:someCustomer" use="encoded" encodingStyle=""/>
                        <soap:body namespace="urn:someCustomer" use="encoded" encodingStyle=""/>
      <service name="someCustomerService">
            <port name="someCustomerPort" binding="typens:someCustomerBinding">
                  <soap:address location="http://foo/bar/someCustomer.php"/>

However, I need to change the add_someCustomerReturn  type from xsd:string to a complex type.

I’ve made several tests variants around trying to add a complex type, like the following:

      <message name="add_someCustomerResponse">
            <xsd:complexType name="respType" >
                        <xsd:element name="someStatus" type="xsd:boolean" />
                        <xsd:element name="someResult" type="xsd:boolean" />
            <part name="add_someCustomerReturn" type="typens:respType"/>

However I always end up having an error like:

Custom tool error: Unable to import WebService/Schema. Unable to import binding 'customerBinding' from namespace 'urn:customer'. Unable to import operation 'add_customer'. The datatype 'urn:customer:respType' is missing. closequotes.png

One thing to note is the above "web service" is using: soap:binding style="rpc". While I am not advocating one over another (document/literal), I personally think that if you stripped the religious and philisophical debates, one can certainly build a RPC-style web service using doc/literal encoding.

The above exceptions funs afoul of what many techies called: Section 5 Encoding

For the above to be resolved, you need to define a complexType reference by wsdl:part “add_someCustomerReturn” in the schema.
To do this, you MUST define wsdl:types and add the schema to the WSDL that defines the complex and change the type=”xsd:string” (of the wsdl:part) to the identifying complexType in the schema (encoded in wsdl:types)

While this is an old article written by Tim, the same principles apply. Do check it out of you need to stimulate your brain: The Argument against SOAP Encoding

Friday, October 24, 2008 12:58:46 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, May 02, 2007

    Finally, OASIS announced last week that it is calling for participation for Web Services Federation. The formation of the WS-Federation Technical Committee is announced here.

    WS-Fed is an important addition to the WS-* protocol suite that enables users to sign-in seamlessly to systems outside of their own organization without requiring (more) new usernames and passwords using Single-Sign-On (SSO) between separate organizations with an established trust relationship.

    WS-Fed builds upon and composes with other WS-* protocols:

    • WS-Fed extends WS-Trust
    • WS-Fed composes with WS-Security and WS-SecureConversation to ensure data integrity and privacy
    • WS-Fed composes with WS-MetadataExchange and WS-Policy to enable simple provisioning and trust relationship configuration

    Does WS-Fed compete with Liberty SAML?

    • Both SAML and WS-Fed enable browser-based identity federation (Passive-Mode)
    • However, WS-Fed enables a superset of scenarios, including:
      • Seamless federation with Web Services and/or Rick-Client applications
      • Separation of identities, token types, protocols and encodings
      • Multi-purpose Security Token Service (STS) that can return tokens stating different assertions based upon the scenario

    WS-Fed adds identity federation capabilities to the existing WS-* suite of protocols resulting in:

    • A single protocol stack that supports the majority of your needs and scenarios
    • Simplified development, deployment, management and control

    The formation of the Technical Committee to drive the standardization of the WS-Fed is an important step in evolution of the industry-wide effort to create a single, comprehensive communication protocol suite that enables many current and new scenarios most effectively.

    Wednesday, May 02, 2007 3:39:08 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, July 07, 2006

    This popped into my inbox a while ago ...


    Contests like this are just great. Not only are you receiving money (if you win... Who cares, even if you dont, a digital mutation of your idea may still evolve to a sellable one), you are competing with the best to generate a innovative, marketable, secured and (hopefully) usable product. The byproduct derived from the entire process would be similar to a mini-version of an RFC. Bad and unsecured ones would have been shot down and the good ones could be made better with a few ingenious tweaks.

    Now only if I can find 25.5 hours in any given day ...

    Friday, July 07, 2006 6:45:38 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • Blasphemy ...

    It is finally published. After many, many, and I mean, many months of paying the process tax for this piece, it is finally LIVE !

    I started this piece with the first ever March 2005 CTP of Windows Communication Foundation (WCF, previously - Indigo) and I went through so many port demos and edit document cycles its so unbelievably painful ...

    But it is really good to see this in online form and shape.

    I started with this idea even though MSFT Corp has explicity stated that it will not support any form of interoperability between WSE 2.0 and WCF, even though it is "theoretically possible to develop Web services using WSE 2.0 in such a way that they can interoperate with WSE 3.0 (and WCF) by using only a reduced set of specifications"

    More importantly, the main reason for the motivation to write such a piece is written in the article itself and I quote:


    ...WSE 2.0 has seen 3 service pack releases since its official launch in 2004. It implemented the OASIS Web Services Security 1.0 specification which was the widely accepted interoperability standard protocols between secured web services as well as the implementations of WS-Addressing, WS-SecureConversation and WS-Trust. It was integrated very nicely into Visual Studio 2003. Even BizTalk Server 2004 carries with it a WSE 2.0 adapter for securing of Web Services. Thus, it would be fair to assume that there is more than its fair share of implementations in the market today.


    Depending on timing, budget, complexity and a whole host of other requirements, some of these applications will need to be moved and migrated to WSE3.0 and some to WCF. Aaron Skonnard has provided a great resource in his “Service Station” column on MSDN on a brief overview on the migration of WSE 2.0 applications to WSE 3.0 ones. However, as stated in his article, there are some major changes in the programming model and architecture in WSE 3.0 and migrating them from WSE 2.0 may not be trivial.

    Another very important factor to take note is while WinFX, and therefore WCF, is available downstream from Windows Vista to Windows 2003 and Windows XP. That is as far down as it goes. There still exists a huge installed base of Windows 2000 Servers out there running on server and data farms and if you need to implement the advanced Web Services stacks on those servers, WSE is still a very important strategy you cannot ignore.

    As noted in the above guidelines, even though Microsoft will not guarantee interoperability between WSE 2.0 and WCF, the good news is that there are a few WSE 2.0 common scenarios, which can allow wire-interoperability with WCF. I will illustrate them in the next section...



    So, this article will outlined WHAT that reduced set of specifications are and HOW to go about using them.

    Many Special Thanks go to Kirill, the Interop PM on WCF, who gave me a couple of tips to get over the port-over humps I had thoughout this piece since last year. And of course, I cannot forget Clemens, who is the catalyst to making this publication happen when he came onboard.

    I hope this helps at least someone out there. Enjoy !

    Friday, July 07, 2006 6:11:57 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, June 07, 2006

    During my webcast on "Why we need Reliablility in SOAP: Web Services", there were a couple of hiccups which hindered a better listening experience.

    1. I cannot see the animation on the slides I am presenting, even though I am assured by the producer that the floor is seeing it. Therefore, I am "guessing" what the audience is actually seeing in my click-animation and gauging my content from there. It was neither easy nor pleasant.
    2. There was a disconnect incident in my demos that also marred the listener's experience. I had to re-login again. Not Good.

    Isnt it ironic? My network connection showed lack of reliability when I am talking about Reliability as a topic. . Now the least I can do is to answer a couple of questions that popped up after the session:

    Q: Is RM available for all the bindings in Windows Communication Foundation (WCF, previously - Indigo)
    A: Yes, it is available for MOST of the standard bindings in WCF. In some bindings such as the netTcpBinding I showed, it is On-by-Default. In bindings such as wsDualHttpBinding where you need correlation of different channels and such, it is Always-On. It doesnt make sense to stick <reliableSession /> in a netMsmqBinding, for example.

    Q: Is this the same WS-RM spec that is authored by IBM, Microsoft and TIBCO ? 
    A: Yes. In my slide, I mentioned - I.B.M and TIBCO. I.B.M is actually the acronym I used for IBM, BEA and Microsoft.

    Q: Can I get the demo you showed? 
    A: No, I am sorry. In any case, my demos will not work with the lastest WinFX B2 bits today. I will need time to port them over. I recommend you go bug Shy when you see him and ask him for his WS-RM demo which consists of a WPF stack in there and a "awesomely" cool Rubik's Cube demo and is 100x better than mine.

    All in all, it is quite a different experience than doing an on-stage presentation, especially when you spent an hour talking to yourself and you cannot see the audience faces and cannot manipulate your content and presentation based on their moods.

    But then again, no one can see that I am wearing my Mickey-Mouse boxers while I am presenting, so I guess that is a good trade-off.

    Wednesday, June 07, 2006 6:06:48 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, May 27, 2006

    Here I am - proud to announce that I will be doing a MSDN Redmond-hosted Webcast right from the other side of the hemisphere in Singapore.

    I will be speaking on concepts of Reliability in Soap:Web Services, why its needed, as well as the context of it in Windows Communication Foundation (WCF, previously - Indigo).

    More importantly, a 40GB Creative (another homegrown Singaporean product) ZEN MP3 player is at stake here waiting to be won. So, do sign up quickly for a chance to win this. Rules here.

    If you are one of those insomniacs in Asia-Pacific, do try to tune-in. I hope this blazes a trail for the other community leaders in Asia-Pacific to follow suit and show that we are right on par there with the best in technology.

    Click here for more details on this webcast.

    Saturday, May 27, 2006 6:03:37 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, May 16, 2006

    Apache Axis2/C version 0.91 has been released via here:

    Key Features

    1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages with complete XML Infoset support
    2. Support for One-Way Messaging (In-Only) and Request Response Messaging (In-Out)
    3. Module architecture, mechanism to extend the SOAP processing model
    4. Context hierarchy
    5. Directory based deployment model
    6. Raw XML providers
    7. WS-Addressing, both the submission (2004/08) and final (2005/08) versions
    8. Transports: HTTP * Both simple axis server and Apache2 httpd module and * SSL client transport - New
    9. Service Groups - New
    10. Service client and operation client APIs - New
    11. REST support (POST case) - New
    12. Module version support - New
    13. MTOM support - New

    Other notes

    1. Interoperability tested with Axis2/Java for XML in/out client and services
    2. Addressing 1.0 interoperability

    Major changes since last release

    1. Full Addressing 1.0 support
    2. Improved fault handling model
    3. SSL client transport
    4. MTOM implementation
    5. Implementation of easy to use service client and operation client APIs for client side programming
    6. REST support (POST case)
    7. Module version support
    8. Service groups
    9. Numerous bug fixes since last release

    Un-Implemented Architecture Features (TBD in 1.0)

    1. Sessions scoping for application, SOAP, transport and request levels
    2. Different character encoding support
    3. Dynamic invocation
    4. Archive based deployment Model

    Un-Implemented Architecture Features (TBD post 1.0)

    1. WSDL code generation tool for stub and skeletons (based on Java tool)
    2. Security module
    3. REST (REpresentational State Transfer) support (GET case)
    4. Web Services policy support
    5. Axis2 Web application (Web App)
    Tuesday, May 16, 2006 5:59:18 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, January 12, 2006

    With regards to my post here, I thought I expand on one of many enhancements that WS-Security Specifications 1.1 brings.

    "MutualCertificate11Security" assertion is one of the few security turnkey assertions in Web Services Enhancements (WSE) 3.0 and what basically it is is that the client and server are authenticated using X.509 certificates (X509SecurityToken). Message-level security is implemented using X509SecurityToken security tokens. This turnkey security assertion requires WS-Security 1.1

    Once that is configured and implemented properly, it is rather interesting to see what transcends on the wire. Here is a brief snippet:

    [wsse:Security soap:mustUnderstand="1"]
    [wsse:BinarySecurityToken ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="...wss-soap-message-security-1.0#Base64Binary" wsu:Id="SecurityToken-76ae..."]MIIBvD...[/wsse:BinarySecurityToken]

    [xenc:EncryptedKey Id="SecurityToken-6ec8..." xmlns:xenc=""]
    [xenc:EncryptionMethod Algorithm=""]
    [ds:DigestMethod xmlns:ds="" Algorithm="" /]
    [KeyInfo xmlns=""]
    [wsse:KeyIdentifier ValueType="...oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="...oasis-200401-wss-soap-message-security-1.0#Base64Binary"]qRTA40Xfk6w1Os3mgpgy8UgwR/Y=[/wsse:KeyIdentifier]

    [Signature Id="Sig-b679..." xmlns=""]
      [ds:CanonicalizationMethod Algorithm="" xmlns:ds="" /]
      [SignatureMethod Algorithm="" /]
      [Reference URI="#Id-5cdc..."]
      [wsse:Reference URI="#SecurityToken-6ec8..." ValueType="...oasis-wss-soap-message-security-1.1#EncryptedKey" /]

    [Signature xmlns=""]
      [ds:CanonicalizationMethod Algorithm="" xmlns:ds="" /]
      [SignatureMethod Algorithm="" /]
      [Reference URI="#Sig-b679..."]
      [wsse:Reference URI="#SecurityToken-76ae..." ValueType="...wss-x509-token-profile-1.0#X509v3" /]

    One thing that you will noticed is that there are 2 Digital Signatures generated.

    The first one has a ReferenceID, which hints that it will be subject to encryption/signatures later on, and it is signed by a EncryptedKey type (which I talked about in my earlier post). Because it is encrypted by a symmetric key "#SecurityToken-6ec8", the [SignatureValue] is rather short and this signature basically signs the soap:Body with an URI of "#Id-5cdc..." The [EncryptedKey] value can be decrypted and derived by the server's private key

    The second signature basically signs the first signature (#Sig-b679...) and it signs it with the Client's Private Key that only the corresponding Public Key Pair can decrypt. The Public Key, together with the client's cert is sent over the wire via a [wsse:BinarySecurityToken] (#SecurityToken-76ae...). Because an asymmetric key is utilized here, the [SignatureValue] is relatively longer than the first signature.

    As we can see from here, the first signature signs the soap:Body and the second signature signs the first signature. These are generally known as "Supporting Tokens". These additional tokens may be specified to augment the claims provided by the token associated with the “message signature” provided by the Security Binding. Supporting tokens may be specified at a different scope than the binding assertion which provides support for securing the exchange.

    There are four properties related to supporting token requirements which may be referenced by a Security Binding: [Supporting Tokens], [Signed Supporting Tokens], [Endorsing Supporting Tokens] and [Signed Endorsing Supporting Tokens]. Four assertions are then defined to populate those properties: SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens, and SignedEndorsingSupportingTokens.

    What I have shown above is known as the [EndorsingSupportingTokens].

    The [SignedEndorsingSupportingTokens] is a combination of [SignedSupportingToken] and [EndorsingSupportingToken] and I will talk about that in a future post.

    Wednesday, January 11, 2006 5:06:42 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, January 10, 2006

    I have been back fiddling at the Web Services Enhancements (WSE) 3.0 technology space for the past few weeks and I am now grokking into the plumbings since there are quite a few forums, blogs, posts out there focusing on the higher-level abstract programming model.

    I am very pleased that WSE 3.0 has implemented WS-Security Specifications 1.1 at its very core, so much so that it is the de-facto security standard to be used in most of the Turnkey Security Assertions that comes with the product.

    One of the things that I have always been asking for through my contacts and channels in the OASIS WS-Security Technical Committee is the ability to sign my document snippets with a symmetric key instead. Since XML-Encryption already utilized symmetric key encryption via the [xenc:EncryptedKey] [1] for performance and throughput reasons, there is no reason why XML-Digital Signature cannot do the same. While the improvements in throughput may be slight due to the fact that in digital signatures, messages are already hashed before encryption, it is still a viable option that should be made available.

    In WS-Security 1.0, this is what is commonly seen in the Digital Signature Parts:

    [wsse:BinarySecurityToken ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="...oasis-200401-wss-soap-message-security-1.0#Base64Binary"
      [Signature xmlns=""]
      [CanonicalizationMethod Algorithm="" /]
      [SignatureMethod Algorithm="" /]
      [Reference URI="#Id-f7e1..."]
      [Transform Algorithm="" /]
      [DigestMethod Algorithm="" /]

      [wsse:Reference URI="#SecurityToken-7b5d..."
    ValueType="...oasis-200401-wss-x509-token-profile-1.0#X509v3" /]

    Now in WS-Security 1.1 via WSE 3.0, I can do this:

    [xenc:EncryptedKey Id="SecurityToken-32e4..." xmlns:xenc=""]
        [wsse:KeyIdentifier ValueType="...oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="...oasis-200401-wss-soap-message-security-1.0#Base64Binary"]qRTA40Xfk6w1Os3mgpgy8UgwR/Y=[/wsse:KeyIdentifier]

      [xenc:DataReference URI="#Enc-0914..." /]
      [xenc:DataReference URI="#Enc-3aab..." /]
      [xenc:EncryptedData Id="Enc-0914..." Type="" xmlns:xenc=""]
      [xenc:EncryptionMethod Algorithm="" /]
      [xenc:CipherData]  [xenc:CipherValue]RLASn...[/xenc:CipherValue]

    [Signature xmlns=""]
      [SignatureMethod Algorithm="" /]
      [Reference URI="#SecurityToken-d217..."]
      [Transform Algorithm="" /]
      [DigestMethod Algorithm="" /]
      [Reference URI="#Timestamp-6f12..."]
      [wsse:Reference URI="#SecurityToken-32e4..."
    ValueType="...oasis-wss-soap-message-security-1.1#EncryptedKey" /]

    Note the fonts in RED. There is a new URI: which ties to a ValueType: A token type of an [xenc:EncryptedKey]

    ... and more importantly ...

    the [SignatureValue] contents is slightly shorter now because it is actually encrypted with a symmetric key now. I know I may be picking here BUT hey, even a single byte in reduction means a lot in throughput performance in terms of wire transfer of documents. .

    There are other improvements WS-Security 1.1 brings over its predecessor 1.0, which I will blog more about as I go along.

    [1] Just a note to defuse any confusion if it crops up: Asymmetric (Public-Private) key technologies are still very much used in WS-Security and other document-related security specifications today. I dont think it will be dropped anytime soon unless Quantum Cryptography takes off mainstream in a big way or the subtle effects of this reverberates adversely through the security space. Having said that, Symmetric (Master/Session) key technologies have a huge place in the security specifications world too, just by the fact that it is a 1000x faster than much-secure asymmetric ones. Therefore, both technologies co-exist and work very well together in the document security space. To put it simply, a symmetric key (KeyA) is randomly-generated (key-length can be specified by the application - the longer, the better) and then used to encrypt/decrypt messages (MsgA). Once that is done - KeyA is then subsequently encrypted by an asymmetric key (KeyB) and then transmitted through the message. Only the holder of the Private-Key pair of KeyB will be able to decrypt KeyA which can then decrypt/encrypt MsgA.

    Monday, January 09, 2006 9:41:51 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, October 24, 2005

    In Web Services Enhancements (WSE) 2.0, one could exercise some control over what one xml element/fragments wants to encrypt within a soap:Body. Therefore, if I wanted to encrypt the account string in my credit card type, I could do something like this:

    [At your Service Side]

    Public Class SecuredCreditCard
      <XmlElement(ElementName:="CreditCardType")> _
      Public Type As String
      <XmlElement(ElementName:="CreditCardAccount")> _
      Public Account As SecuredString
    End Class

    Public Class SecuredString
      'Set the Oasis Id that our security reference will point to
      <XmlAttributeAttribute("Id", _
    Namespace:=".../2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd")> _
      Public ID As String
      <XmlText()> _
      Public Data As String
    End Class

    [At your Calling side]

    Dim a As localhost.IndexWse = New localhost.IndexWse
    Dim b As localhost.SecuredCreditCard = New localhost.SecuredCreditCard
    Dim z As localhost.SecuredString = New localhost.SecuredString

    Dim c As SoapContext = a.RequestSoapContext

    b.CreditCardType = "VISA"
    z.Id = "" 'or some guid
    z.Value = "123-456-789"
    b.CreditCardAccount = z

    c.Security.Elements.Add(New EncryptedData(tok, ""))

    Note: To reduce headache-inducing typo bugs, you may want to use some WSE Constants such as

    The end result of this is a soap:Body on the wire looks like this:

     <CreditCardAccount d4p1:Id="" xmlns:d4p1=".../2004/01/oasis- 200401-wss-wssecurity-utility-1.0.xsd">
      <xenc:EncryptedData Id="EncryptedContent-3d793117-f020-4236-a0a0-0ed545d9bf1a" Type=".../2001/04/  xmlenc#Content" xmlns:xenc=".../2001/04/xmlenc#">
      <xenc:EncryptionMethod Algorithm=".../2001/04/xmlenc#aes128-cbc" />

    While I dont know how much of performance benefits this has over one that has the entire SecureCreditCard encrypted (since it is an symmetric-key encryption at its core), I think in terms of latency and throughput, it does offer some benefits especially with a sizable payload (>20-30 kb, for instance ?)

    Windows Communication Foundation (WCF, previously - Indigo) does not currently have that feature build in at the moment (Sept05-CTP or known as the PDC-bits). In other words, in WCF today, you encrypt the entire contents of the soap:Body, lock-stock-barrel. I would still love that WSE feature in there: To be able to exercise finer grain control over what I want to or not to encrypt within a soap:Body.

    Would really like to find out if I am the only odd one out there. Any users using that existing WSE feature out there that would love to see the same in WCF or do you have other better ideas ? Leave a comment or email me via the contact link on the side. Thank you.

    BTW: Whether you encrypt certain elements of the contents or encrypt the entire contents of the soap:Body, both are WS-Security Specifications compliant.

    Monday, October 24, 2005 1:00:00 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, October 05, 2005

    Another speaking assignment that landed at my desk is for me to talk about "Web Services Security: How to track along the Security Standards Jungle" on the 21 October 2005

    Somehow, I tend to attact the dry topics . This event is owned by OASIS and XMLOne Usergroup. More information can be found here.

    If you are around the vicinity, do feel free to drop by and catch up.

    Wednesday, October 05, 2005 12:52:22 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, July 21, 2005
    Wednesday, July 20, 2005 10:38:17 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, May 22, 2005
    I hope this turns out better than this.
    Saturday, May 21, 2005 6:53:09 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, February 18, 2005

    Benjamin points to a great tool from MSFT Corp Research in Cambridge that acts as a security diagnosis tool for WSE2 policy files...

    Worth trying and looking into even though it is unsupported...Since when is a product or tool that rolls out from Research supported in the commercial production world anyways...

    Another +1 for Microsoft for the raising awareness in security, esp in the realms of XML SOAP Services.

    Friday, February 18, 2005 12:43:51 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, February 06, 2005

    SDA-Asia has recently published one of my articles online. In this article, I talked about how Web Services Enhancements (WSE) can be used to solve Real-World business problems with some proper thought and design processes.

    This is not as technical an article comparred to the ones I have written before, however, I feel it gives a good overview and insight to what the advanced XML services are and how to make use of some of them to solve some of the business problems of today...and needless to say, WSE 2.0 is THE tool to do that today in .NET

    I have spent a fair amount of time writing up a REAL technical article (on WSE, of course) recently which I hope will get published soon enough. Will update all once it goes live. Enjoy.

    Sunday, February 06, 2005 1:00:31 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, January 26, 2005

    Finally, this is done. Read the cover story here.

    Even though I usually dont advocate the use of SOAP to transfer large BLOBS of binary bits (I tend to think that there are slightly better ways of transferring files and/or attachments), I do believe that there will be more and more calls for uses for it and that is why I think this is an important specification which is way better than W3C's SwA or MSFT Corp's/IETF's  DIME (Can you say Security ?). The latter, incidentally, is being implemented by Web Services Enhancements (WSE) 1 and 2.

    Of course, since DIME is being superseded by MTOM, I am really looking forward (hopefully) to the implementations of it in WSE 3.0

    Wednesday, January 26, 2005 9:16:26 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, January 25, 2005

    William Stacey has outdone himself again. He has blogged on how to create SecurityContextTokens without X509 Certs.

    He has beaten me to it. As I have said in a comment to his blog:

    ...I knew something like that would be very useful and there are tons of requests out there for the use of SCT without X.509 because of cost issues or the server admin doesnt want to install them for whatever reasons.

    I was on my way to implementing it, then I took some time off to look at the specifications for the exchange of entropy values, then I got derailed by some work committments and after that I just got lost...

    It is so good for you to come up with this. It is excellent. I would have to try it and feedback. Many people will thank you for it.

    Julie, if you are reading this, hopefully this will help solve a problem of yours that is way loooong overdue.

    Tuesday, January 25, 2005 11:26:20 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, January 19, 2005

    I recently extended a chat program written in Web Services Enhancements (WSE) 2.0 utililizing the TCP transport protocol. I wanted it to run over the internet now. This was prompted by some members of our Singapore Professional DotNet Usergroup who wanted to implement a mini Pub-Sub (aka WS-Eventing) project using the tcp protocol.

    They had indicated that they had some trouble binding the FQDN specified for the URI in the EndpointReference to a local network interface. If this cannot be resolved, the binding will fail.

    At the most basic level, the EndpointReference.Address is both the name of the target and its location. For example, [http://localhost/SomeService] can be used as a name and a transport address. WSE 2.0 comes with an extended model to allow a single named service to be hosted on multiple transport addresses. This can also be useful if we want to apply a single corporate policy on them.

    This is where EndpointReference.Via comes in. It allows you to host a well-known service that can only be accessible via different transports such as the soap.tcp protocol of WSE 2.0 and others.

    For example, my well-known service is hosted at soap.tcp:// (or soap.tcp://, if you dont have a DNS tagged to it). This is the public FQDN address of the service. For the broadband cable and ADSL users of dynamic IPs, this address may be the address of your home network router.

    Now, your WSE 2.0 application has a SOAP Receiver object that allows your application to listen for SOAP requests coming in on WSE2-custom defined transports. Once you define your own address on your own listening machine such as soap.tcp://, you would now have 2 URIs:

    Public Facing: soap.tcp://
    Private Internal: soap.tcp://

    The Public Facing well-known URI becomes the EndpointReference.Address while the transport address mechanism becomes the EndpointReference.Via

    In other words, soap.tcp:// will listen for any messages that is sent to soap.tcp:// (the address element in the WS-Addressing headers). Put it in another way, the custom soap.tcp transport will only accept messages sent to soap.tcp:// if they arrive via the internal address:

    The Via address is not in the message itself, only the well-known URI is. Based on the network address the message is being received on, the custom soap.tcp transport mechanism will know how use both well-known and private URIs to dispatch the message to the registered and configured-properly SOAP Receiver.

        EndpointReference EPR = new EndpointReference
        (new Address(new Uri("soap.tcp://")),

        new Via(new Uri("soap.tcp://")));

        SoapReceivers.Add(EPR, yourOwnSoapReceiver);

    The last step you need to take is to be able to forward all requests going to the well-known URI (soap.tcp:// to your local machine with the internal IP

    This is not something you can do in WSE 2.0 or in your machine. This has to be done at your broadband or cable router. You just have to forward requests coming in to your Public port:2088 to the Private port:2088 of machine (Note that these ports doesnt have to be the same number at all)

    Of course, the huge assumption is that you have control over the port routing and forwarding of your broadband or cable router (which may be rather tricky if you are within a corporate or organizational boundary) BUT technically, you will be able to carry out a p-2-p SOAP message chat or even do a Pub/Sub model approach with your own implementation of the “Notification” and “Solicit-Response” message-exchange patterns over the internet using the custom soap.tcp protocol of WSE 2.0

    [Author Note] What do ya know ? I just found that that Hervey has got an even better post on the EndpointReference.Via of WSE 2.0 here.

    Wednesday, January 19, 2005 1:47:59 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, January 13, 2005

    William Stacy has a new blog in MSN Spaces and he blogged about a topic that has spurned from recent activities in the WSE newsgroups.

    It is about the security and the use of username tokens in the real world, specifically when it relates to passwords being stored as hash in the user database.

    William proposes a method here to solve the issue of how to authenticate username tokens embedded in _WS-Security Specs_ security headers.

    In my own opinion, his case represents a very major common representation of how passwords are stored in the database. They are mostly and SHOULD be hased. To add another realm of security, SALT is used. However, I dont really agree that his method may prove to more secure. In fact, I think it gives a somewhat false sense of security (and William, please correct me if I am wrong anywhere).

    1)   By using your verifier as a matching mechanism to gain authentication, then this verifier (SALT Hash and all) effectively becomes a password. If Mallet steals the hash from the user database, nothing prevents him/her from writing a client that sends the hash and thus he would authenticate successfully. This is exactly what the hash scheme is trying to avoid in the first place.

    If used this way, the hash is no safer than storing the passwords in clear text in the database...which ultimately means that the weakest link is still the security of the Username Database which must be protected at all costs.

    In other words, this must be made known clearly so that it doesnt preach a false sense of security that people think that this scheme NOT only protects their cleartext password BUT also their SOAP calls as well.

    This post here explains real well on my thoughts as well.

    2)   SALT should be a completely random value and should be algorithmically introduced to further obfuscate the one-way hash. In your approach, it seems that the SALT is tied very much to your username (am I wrong ?). This doesnt help much because I dont need to guess your publicly-available username, there are only a handful of hashing algorithms out there and you are NOT passing any SALT into your PasswordDeriveBytes constructor. In fact, the only saving grace is the iteration count which basically sets the number of iterations for the operation. Is that enough ? I believe it may serve well for some smaller-scale simpler systems BUT I dont know how it sits well with some of the security policies of bigger enterprises.

    IMHO, I think the current username tokens as defined by WS-Security doesnt fit very well into most EXISTING user databases which store passwords as hashes which may or may not be SALTED. I dont think there is a clean way to do this in WSE without using or representing the hashes as passwords. However, I am still thinking about this issue and will blog more about it later if (not when) I reach enlightenment.

    Your approach, however, does allow passwords to remain as they are in the EXISTING user databases. The only obstacle you require is a change in the schema of that table, which requires management approval and buy-in and usually triggers off many other related procedures, and that in my experience, is sometimes harder than finding the password from a hash.

    [Author Note]: This topic has got nothing to do with the security of username tokens as I have blogged about earlier here. This is all about the authentication of username tokens with the stored credentials in the user databases.

    Wednesday, January 12, 2005 11:09:54 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, January 12, 2005

    After installing Web Services Enhancements (WSE) 2.0 SP2, the most natural thing for me to do is to run my previous WSE 2.0 SP1 projects and see if it works with the new assembly.

    Most of it still do run <phew>. A couple of them (specifically the SOAP Routing ones) did NOT run as intended. A further drilldown into the code revealed that the ExtendedSecurity doesnt serialize properly if you are planning to send another set of Security Headers to the next SOAP node...In fact, it doesnt get serialized at all.

    ...Obviously, this next node cannot be the ultimate soap receiver as target service cannot process 2 security headers as specified in the _WS-Security Specs_. You can refer to my previous discussions with HerveyW here and here.

    So, if your next node is another SOAP Router and you need a different set of Security Headers for the next node to process, this is how to do it with the ExtendedSecurity function in SP2:

    You need to add a Security Utility Timestamp into the Security Header in order for the ExtendedSecurity function to serialize a new set of Security Headers properly.

    Dim t As Utility.Timestamp = AnotherSecurityHeaderBlock.Timestamp

    Thereafter, when you call the ExtendedSecurity function and add this new Security Header block, the serialization will take place.

    In SP1, it is NOT necessarily for you to add this timestamp.

    The WSE team has confirmed this as a workaround to this minor bug.

    Wednesday, January 12, 2005 10:38:07 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, December 11, 2004

    With reference to my earlier post here, I had explained how we can encrypt the Usernametoken element <wsse:UsernameToken> if we choose to use the PasswordOption.SendPlainText enumeration, for real-world reasons such as

    • Windows Authentication
    • Passwords are stored as Hash in the UserDB

    Other elements in the <wsse:Security> Header element can be encrypted too, although great care and design must be taken as it may reduce the extensibility of SOAP Headers through routing intermediaries. One of them is the <Signature> element.

    As I had explained in another post here, digital signatures can and may be verified for authentication and trust by any SOAP node. If the <Signature> element is encrypted, we may be preventing any SOAP intermediary from authenticating and verifying the digital signature. Unlike digital signatures, <xenc:EncryptedData> elements are encrypted for a specific receiver in mind and therefore, only that one party SHOULD be able to decipher it with a corresponding Private key or shared secret. SOAP intermediaries, trusted or not, SHOULD NOT be able to decrypt or view the the encrypted content(s) and therefore cannot authenticate and verify the signature.

    However, if one should decide that their dispatching mechanism is based on a non-intermediary route or if the <Signature> element may not be meant for the ultimate SOAP receiver and therefore can be removed by the SOAP intermediary, this can be done easily as well with WSE 2.0.

    The key is to create a MessageSignature on its own and assign it an ID. Here is the code snippet on how to implement it:

    Dim a As New MessageSignature(yourSignatureToken)
    Dim g As Guid = g.NewGuid
    a.Signature.Id = g.ToString


    Context.Elements.Add(New EncryptedData(yourEncryptionToken, "#" & a.Signature.Id))

    And the wonderful result that comes out from the oven: (geez...I need a life )

    <wsse:Security soap:mustUnderstand="1">
    <wsse:BinarySecurityToken ValueType="" EncodingType="" wsu:Id="SecurityToken-e8f64eea-1d63-4db2-943c-9bfb5dfccbfc">MIIBxDC...du2fPMER8ajJfl</wsse:BinarySecurityToken>
    <wsse:UsernameToken wsu:Id="SecurityToken-3370d9ae-deb9-4a01-9b9c-c8dd072568fa">
    <xenc:ReferenceList xmlns:xenc="">
    <xenc:DataReference URI="#EncryptedContent-0e6936bf-67a5-48a5-ba8a-d9ba6141e75f" />
    <Signature Id="2c091bb3-bcdc-4da1-97c5-dcd60dac7312" xmlns="">
    <xenc:EncryptedData Id="EncryptedContent-0e6936bf-67a5-48a5-ba8a-d9ba6141e75f" Type="" xmlns:xenc="">
    <xenc:EncryptionMethod Algorithm="" />
    <KeyInfo xmlns="">
    <wsse:Reference URI="#SecurityToken-3370d9ae-deb9-4a01-9b9c-c8dd072568fa" ValueType="" />
    <xenc:CipherData>  <xenc:CipherValue>rFfJS87yAdFFkW1dVbot...tJ+9U8+CU5qsI=</xenc:CipherValue>


    Voila! The Red bold font will show that the Signature Element is now encrypted.

    Saturday, December 11, 2004 8:14:03 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • To slightly expand on my post and Hervey's a little bit further, there was mention on the use of Enveloped Signatures in the SOAP Headers. Enveloped Signature (as defined by XML-Digital Signature) is a signature over the XML content that contains the signature as an element. The content provides the root XML document element. Obviously, enveloped signatures must take care not to include their own value in the calculation of the SignatureValue. In other words, Enveloped Signature would sign the contents of the SOAP headers WITHOUT the signature. This is the only way a Security header can be signed without creating a circular reference dependency.

    To do the above, you are enforcing the prevention of intermediaries from modifying the SOAP Headers.

    However, as taken from the _WS-Security Specs_

    Because of the mutability of some SOAP headers, producers SHOULD NOT use the Enveloped Signature Transform defined in XML Signature. Instead, messages SHOULD explicitly include the elements to be signed. Similarly, producers SHOULD NOT use the Enveloping Signature defined in XML Signature [XMLSIG]

    WS-Security doesnt *believe* in the Enveloped Signatures because it stands on the belief that SOAP Headers are mutable. Since SOAP Headers can change and the likelihood is there that a SOAP intermediary can change the headers, an Enveloped Signature would not be as extensible and work as well.

    I am a strong believer of that. If a normal signature is used instead of an enveloped one, then an intermediary can safely add more tokens and more signatures to a Security header targeted at another node on the message path...and that is why there is WS-Security. Security cannot just be based on End-to-End scenarios or else SSL / HTTPS will suffice.

    I also further believe that an intermediary should be able to extend Security headers which are meant for other target nodes. Since a SOAP node can only process a single Security Header (because of re-ordering constraints of SOAP Headers), this option may not be as far-fetched or ridiculous as it may sound.

    Of course, anyone can still choose to implement Enveloped Signatures over their SOAP Headers if they are just implementing End-to-End scenarios and enforcing non-tampering measures over any desired or un-desired intermediaries. However, extensibility may not be an option here should intermediaries be required to offload certain processing functionality off the ultimate receiver or even add more tokens and signatures along the way.

    Saturday, December 11, 2004 2:57:32 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, December 09, 2004

    I have been noticing an increasing number of emails and newgroup threads asking for the security of Usernametokens as specified by _WS-Security Specs_ on OASIS. Most people would like to use it because it is the only alternative they have and there are no other options for using X.509 PKI Digital Certificates. Here is my personal take on it.

    I think some of the security concerns are slightly misplaced here. Firstly, I dont think WS-I or OASIS would include Usernametokens inside the WS-Security Specifications if they doubt its security. As I would like to say, --- Implementation is key.

    A Username token does NOT use any simpler or less-standard security algorithm than any other tokens. In fact, it uses the same hashing algorithm, symmetric algorithm such as the 128-key Cipher Block Chain (cbc) Advanced Encryption Standard, etc as any other token. Many people, also, do not realize that the same symmetric algorithm is used to encrypt the SOAP message body when an asymmetric X509SecurityToken is used as well. The asymmetric key algorithm is only used to encrypt the secret key that is doing the actual symmetric encryption processing. This is done for the purpose of reducing cipher bloat and increasing processing speed. The paranoia in me, however, would go for a higher-bit key implementation, which is possible.

    Remember that your secret can be stolen and kept for years and tried to be broken with much higher-end and cheaper deciphering machines in the future. OK, OK, that is my paraniod self talking.

    I believe when statements are made against the security of Usernametokens, they are made against the passwords of the Usernametokens. Therefore, the statement: "Usernametokens, on their own they are only as secure as the passwords"

    Usernametokens are as secure as your passwords. That means that if you have a good security policy on how your company treats passwords, ie...

    1. Minimum password length
    2. Implementation of alphanumeric and other different characters and symbols in password
    3. Password change frequency (in months instead of years )
    4. Elimination of Weak Passwords such as using names and such
    5. ...

    you should NOT be so fearful of using a Usernametoken in your Web Service implementation.

    On the other hand, if you don't treat or administer your passwords with good password policies, then you cannot expect Usernametokens to give your message as secure a protection as you would like.

    I would also recommend using the PasswordOption.SendNone, if possible. The hash of the password and other elements are used to produce the cipher. NO password is sent over using this enumerated option. Of course, the only caveat is except through a dictionary attack, which of course, can be made so much more difficult (or almost impossible) by having a good password policy administration system.

    If you have to send your Usernametoken over in PasswordOption.SendPlainText for whatever reasons (using Windows, LDAP Authentication or you may have hashed versions of your passwords stored in your UserDB), you SHOULD encrypt the UsernameToken with a X.509 digital certificate. Read my post here for my own implementation of it.

    Another thing to take note is one that relates to the real world and why I believe Usernametokens have its place here. It is easiest to implement and common in any business environments. Therefore, it can be plugged into any existing IT systems with relatively lesser effort. Also, X509 digital certs are usually used to authenticate machines and / or companies, it would be more expensive and unrealistic to expect every user in a 100+ user organization to have a digital cert and a private / public key pair. Therefore, I strongly believe that Usernametokens are more appt to authenticate the users themselves in the real world and will continue to be one of the most popular way to authenticate users in the near biometric-less future. However, if you are using authentication between machines, you should opt for X509 digital certs instead.

    [Author note] I believe WSE 2.0 SP2 has taken some lengths to make sure that Usernametokens which transmits a clear text password are now encrypted.

    • For security reasons, it is strongly recommended to encrypt Username tokens, especially when they contain password information. The SecurityTokenServiceClient class now automatically encrypts any UsernameToken security tokens included in outgoing SOAP requests. Similarly, the SecurityTokenService class automatically encrypts any UsernameToken security tokens included in outgoing SOAP responses.
    Thursday, December 09, 2004 1:57:26 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, November 29, 2004
    Andrés G Vettori has done it again...
    Monday, November 29, 2004 8:25:11 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, November 27, 2004
    Can or Should a SOAP node process multiple security headers ? Should Trust be End-to-End or Node-to-Node ?
    Saturday, November 27, 2004 10:18:35 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, November 21, 2004
    Sunday, November 21, 2004 7:48:41 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, November 20, 2004
    I came across some questions pertaining to how the asymmetric keys of X.509 PKI Digital Certificates are being transmiited during SOAP Message exchanges for both XML-Encryption and XML-Digital Signature. There seems to be some sort of slight confusion here so I will explain in a more user-friendly fashion here.
    Saturday, November 20, 2004 8:19:49 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, November 17, 2004
    Tuesday, November 16, 2004 10:12:28 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, October 29, 2004
    Friday, October 29, 2004 3:01:10 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions