none
WCF client and WS-Security

    Question

  • Hi

    I am pretty new to WCF, but experienced with .NET and C# in general.  I have a task at work that is a little unique.  I just got some of the details and still working on getting full details, but I think what I know now is enough to ask this question and give enough of what I'll need to do to hopefully get some direction from some of the WCF experts here.

    Basically, I'll be building a client that needs to send a SOAP message to a remote web service (our customer) that is not .NET on the server side.  We have to first go through an initial call that gets back a cookie, then we have to do something with that cookie and from that we can "manually/programmatically" build our SOAP message to POST to the service.  We need to encrypt the SOAP message, so WS-Security is involved.

    All of this has to be done programmatically, not using a proxy built with svcutil, etc.  This is because of the cookie scenario where we have to talk to an intermediate server first, get the cookie, then build the SOAP, then encrypt, then built an HttpWebRequest to post to the remote service.

    I'm interested in suggestions, but this has to be done fast so any recommendations for "a better way to do it would be...." are appreciated, but at this point we have to get this done yesterday (and I still don't know all the details...joy).  So if there are SOAP classes to use, WCF classes, etc to 1) build the SOAP and 2) encrypt using WS-Security that I can use programmatically to basically do what a proxy and the WCF run-time would do for me, please let me know.

    I VERY much appreciate ANY input you might have!!


    Friday, June 05, 2009 1:48 PM

All replies

  • First off all if I understaood well you have  2 issues in your post:
    One is defined a custom soap message and then encrypt the message.

    So the the first one May be check  what is so call WCF and POX   http://msdn.microsoft.com/en-us/library/aa738456.aspx, this is dedicated to build custome  message.
    Other solution you willhave to approche and define your own custom SOAP headers

    Next for encryption I would recommand to use message encryption becasue you can granularu encrypt all or partially the message.
    This is something that will takes ti,e anyway if you will have to build allthis through code.

    regards
    serge


    Your experience is build from the one of others
    Friday, June 05, 2009 2:03 PM
  • Thanks for the input.  I'm reading the article that you linked to now.  My only initial thought is that we do need to send SOAP and standard SOAP not just POX, it is just that we need to build it dynamically.  We can't just instantiate a proxy and call the service.  We have to call a service, get a cookie back, then build the SOAP, then programmatically sign and encrypt the message body and have that all in a normal SOAP mesage built just like it would be built if we were using all the built in framework components in WCF to generate a proxy and use WS-Security (behaviors?) to sign and encrypt the message.  most of this would be done under the covers by WCF, but in our case we have to do this ourselves.  I think building a SOAP POX payload would not be too hard, but how to I programmatically and dynamically build in the WS-Security piece?  I can XML encrypt the body, but in looking at the SOAP sample we're to send to our client's web service, there are different elements in the SOAP and info in the SOAP header that WS-Security provides that us just XML encrypting the message body won't provide.

    Thanks for any help!!!
    Friday, June 05, 2009 3:50 PM
  • cbrya

    If you have VS 2005 available, you can build the XML assertions (Timestamp, Tokens, Keys) manually.  I am sure there is a way to do it on 2008 (which is what I am currently looking for).  Specifically there is an example of building out the XML headers yourself; look in the samples in the WSE 3.0 download.   Look at the sample WSESecurityAnnonCode (as compared to AnnonPolicy, which uses the proxy). I am currently doing a similar project hitting a MutualCert secured xFire service.

    Hopefully this is what you are talking about as a custom policy.
                // Create an instance of the Web service proxy
                WSSecurityAnonymousServiceWse serviceProxy = new WSSecurityAnonymousServiceWse();
    
                // Configure the proxy
                ConfigureProxy( serviceProxy );
    
                // This following code sets the same policy as the declarative one on wse3policycache.config
                AnonymousForCertificateAssertion assertion = new AnonymousForCertificateAssertion();
                
                assertion.ServiceX509TokenProvider = new X509TokenProvider (StoreLocation.CurrentUser,
                                                                            StoreName.My,
                                                                            "CN=My Cert",
                                                                            X509FindType.FindBySubjectDistinguishedName);
    
                assertion.Protection.Request.SignatureOptions = SignatureOptions.IncludeAddressing |
                                                                SignatureOptions.IncludeTimestamp |
                                                                SignatureOptions.IncludeSoapBody;
                assertion.Protection.Request.EncryptBody = true;
    
                assertion.Protection.Response.SignatureOptions = SignatureOptions.IncludeAddressing |
                                                                 SignatureOptions.IncludeTimestamp |
                                                                 SignatureOptions.IncludeSoapBody;
                assertion.Protection.Response.EncryptBody = true;
    
                assertion.Protection.Fault.SignatureOptions = SignatureOptions.IncludeAddressing |
                                                              SignatureOptions.IncludeTimestamp |
                                                              SignatureOptions.IncludeSoapBody;
                assertion.Protection.Fault.EncryptBody = false;
                assertion.RequireDerivedKeys = true;
                assertion.MessageProtectionOrder = MessageProtectionOrder.SignBeforeEncrypt;
    
                // Set the policy onto the proxy
                Policy policy = new Policy();
                policy.Assertions.Add(assertion);
                serviceProxy.SetPolicy(policy);



    Ubuntop
    Friday, June 05, 2009 6:30 PM
  • -> So if there are SOAP classes to use, WCF classes, etc to 1) build the SOAP and 2) encrypt using WS-Security that I can use programmatically to basically do what a proxy and the WCF run-time would do for me, please let me know.

    WS Security is implemented by WCF's security channel layer, and WCF doesn't provide any public API which you could use to programmatically encrypt the SOAP messages. So WCF is not the choice for you.

    Hope this makes sense to you.

    Thanks
    Marco
    Another Paradigm Shift
    http://shevaspace.blogspot.com
    Tuesday, June 09, 2009 5:49 AM
  • .-1  Marco Zhou said

    "WS Security is implemented by WCF's security channel layer, and WCF doesn't provide any public API which you could use to programmatically encrypt the SOAP messages."

    Question:
    if WCF WS-security is implemented by the security layer,
    what and how can I then configure WCF based WS-security behaviours and/or policies?

    Question:
    Which standards such as desribed by
    http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf
    are implemented by WCF based WS-Security?

    Looking at the document for which the link is given above, there are 5 persons from Microsoft which where adding theire bits to the document; It would be nice to hear theire voices here and tell us all what we can expect in this regard by WCF and how they think that WS-Security interoperabiliyt from a WCF Client to an Axis2-1.5.1 Server from Apache ORG is provided.

    Axis2 uses the Rampart Modul to implement WS-Security.

    Any examples would be welcome here as well.

    Josef.Stadelmann
    @axa-winterthur.ch

     

     


    Sepp
    Monday, October 04, 2010 11:56 AM