locked
Schema as service + https (encryption at transport) + message signing (no encryption) RRS feed

  • Question

  • Hi,
    I would need to expose a schema as a web service with security.

    1. Source : BizTalk 2010
    2. Target : Pega / Java based systems
    3. Encryption : Transport level
    4. Signing : Message level
    5. Special requirement : Send unsecured responses, supress timestamps

    Can this be done.. ?

    For a start we wanted to achieve only Message Signing.

    1. I exposed a schema as service.. and used BasicHttpBinding .. was able to consume.
    2. Then changed to CustomBinding.. 
    a. EnableUnsecuredResponse = True
    b. IncludeTimestamp = false, Also replayMessages in client and server = false to supress timestamps

    What BizTalk is expecting is that I sign and encrypt my message.
    Can I just make it to accept messages that are signed?

    When I move to SSL (encryption) + Message Signing .. what will be the challenges.
    Do I need to use Custom Binding or can it be achieved with WsHttpBinding (Mode : TransportWithMessageCredential)

    Praveen Behara
    MCST : BizTalk Server 2006 R2, 2010

    Tuesday, January 14, 2014 5:03 PM

Answers

  • As part of the "Publiosh Schemas as a WCF" you get an option to generate the "Receive Port" under a specified application. When you do that the Port created will have all the WCF Level contracts including the ones the references point to. You can then change these as per your requirements.

    Also while publishing the WCF As Schemas, you'd get advanced options that will allow you to control pretty much all aspects of the WCF Endpoint.

    Regards.

    • Marked as answer by Pengzhen Song Thursday, January 23, 2014 8:46 AM
    Monday, January 20, 2014 4:20 AM

All replies

  • If you change your binding to SSL then there is nothing that BizTalk would do. This as a change implies that the schema you;ve hosted under IIS should have an HTTPS binding (also, in addition to the HTTP binding). The transport level encryption is handled by the transport endpoints.

    If you wish to sign the messages, then your message should have a provision for storing the digital signature and the associated checksum somewhere in the message schema. On the Receive side (BizTalk) you;d need to create a custom pipeline that handles the "Decode" stage which would validate the signing certificate (the same should be available in the host account certificate store on the BizTalk Machine), using the certificate (thumbprint + CAPICOM API) validate the message signature.

    You would want to incorporate a custom disassembler (if you do not want the message schemas to incorporate the signature + checksum details) or use the XML Disassembler otherwise. You may also use the BizTalk Party Resolver (that uses X.509 partner certificates published against account in AD for identifying the partner) or build your own party resolver (SDL Sample) to identify the caller based on the signing certificate.

    Regards.

    Wednesday, January 15, 2014 5:16 AM
  • hi Shankycheil,

    Thanks for your reply.
    However, I couldn't find the SDL sample in our BizTalk installation folder samples.

    Currently, we have shelved the SSL requirement. 
    The consumer side would only sign the body of the message. 
    We have to validate the signature on BizTalk end. 
    The service like I mentioned above is schema exposed as WCF service where I cannot put the line ProtectionLevel = ProtectionLevel.Sign. 

    Configuration of my port:
    Type : WCF-CustomIsolated, the binding is CustomBinding (which forces ProtectionLevel.EncryptAndSign)
    ReceiveHost : BizTalkIsolatedHost (which means this would run on IIS process.. the AppPool has been enabled for 32 bit applications also)

    I built two flavours of custom receive pipeline with configs as below...
    1. A MIME/SMIME component in DECODE stage (Allow Non-MIME messages => true, Check revocation list => false).. 
    In disassembler stage... a XmlDisassembler

    2. XmlDisassembler in Disassemble stage 
    Party resolution component in Resolve Party stage

    Both of them were not validating the signature.
    And they keep on saying that the Body of the message is not encrypted.

    What am I missing here?



    Praveen Behara
    MCST : BizTalk Server 2006 R2, 2010

    Friday, January 17, 2014 2:49 PM
  • did not notice the misspelling on my part till I read your response. The SDK Sample I'm referring to is available at http://msdn.microsoft.com/en-us/library/aa559177.aspx

    Also have you had a look @http://msdn.microsoft.com/en-us/library/aa559925.aspx which gives details on How to Receive Signed Messages. There is also a link to help you with the configuration of the receive location.

    Regards.

    Friday, January 17, 2014 4:30 PM
  • hi Shankycheil,

    I think I am missing something out here.. I keep getting this error.

    The 'Body', 'http://schemas.xmlsoap.org/soap/envelope/' required message part was not encrypted

    How can I ensure that the contract that gets generated (don't where it is generated) lets me have somehow configure ProtectionLevel = ProtectionLevel.Sign. I have created the pipeline with MIME and XmlDisassembler, changed the automatically created receive location to use the new pipeline on the receive side.. set as Custom Binding and configured it similar to my pure WCF services that have been successfully tested with our consumers. :(


    Praveen Behara
    MCST : BizTalk Server 2006 R2, 2010


    Saturday, January 18, 2014 5:38 PM
  • hi Abhishek0127,
    If it worked for you .. can you please let me know the scenario for which you implemented this? I would need if

    1. You exposed a schema as a WCF service
    2. How did you ensure that the ProtectionLevel is pegged down to ProtectionLevel.Sign
    3. How did you avert the error that the body is not encrypted

    A detailed reply would be pretty useful.. since I am struggling with this for quite sometime now.



    Praveen Behara
    MCST : BizTalk Server 2006 R2, 2010

    Sunday, January 19, 2014 9:17 AM
  • What you want if controlled by the WCF-Custom configuration on your receive location. Check http://msdn.microsoft.com/en-us/library/jj572861(v=bts.80).aspx and focus on the combination of SecurityMode [which in your case should specify transport] while the TransportLevelProtection should be set to sign.

    I get the feeling that your SecurityMode is set to Message (which implies an encrypted message - default) while the messages you're getting are only signed thus resulting in the error.

    Regards.

    Sunday, January 19, 2014 9:50 AM
  • Hi Shankycheil,

    You are correct in saying that our service is doing EncryptAndSign.. 
    but that is not under my control.. since the artifacts i.e. IIS appliction, port etc., are created by the "BizTalk WCF Service Publishing Wizard".
    Now, I am required to change that default behaviour in that "unseen" contract to ProtectionLevel.Sign.
    I am guessing that I would require to use a custom binding in this case.. but not sure if it would work.


    Praveen Behara
    MCST : BizTalk Server 2006 R2, 2010

    Sunday, January 19, 2014 8:09 PM
  • As part of the "Publiosh Schemas as a WCF" you get an option to generate the "Receive Port" under a specified application. When you do that the Port created will have all the WCF Level contracts including the ones the references point to. You can then change these as per your requirements.

    Also while publishing the WCF As Schemas, you'd get advanced options that will allow you to control pretty much all aspects of the WCF Endpoint.

    Regards.

    • Marked as answer by Pengzhen Song Thursday, January 23, 2014 8:46 AM
    Monday, January 20, 2014 4:20 AM
  • Hi Shankycheil,
    Thank you for all the guidance... however, we couldn't do this just through configuration.
    This is what finally worked for us.

    The whole time we were searching for BizTalk capability.. when we should have searched for WCF extensibility.

    http://zamd.net/2008/02/10/setting-protectionlevel-from-config-file/
    http://adilakhter.com/category/software-development/net-development/c/

    We had to do a small code change in one line.. instead of null.. changed it to desired default value
    propertys.Add(new ConfigurationProperty(PROTECTION_LEVEL_ELEMENT_NAME, typeof(ProtectionLevel), ProtectionLevel.None, ConfigurationPropertyOptions.IsRequired));
    With null value in code, it was showing "object reference not set" when opening config file in SvcConfigEditor.

    1. First we compile code and GAC it.

    2. We are supposed to create a new custom endpoint behavior and register it in machine.config
    I work on a 64 bit infra and our assemblies are 4.0 versions.. hence I changed it in the 2 files.. need to keep it consistent in both
    "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config"
    "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config"
    Once this is done, we will be able to see the behavior add it to the Endpoint Behavior in the port.
    We couldn't avoid changing the machine.config.. 
    i.e. adding the behavior in BtsntSvc64.exe.config or btsmmclauncher.exe.config didn't list this behavior.

    3. Create a bin folder in the IIS application (auto-generated).. and put the dll in the folder
    Without this, if one browses the application.. it throws an error.

    4. Now, open the receive location.. do the regular configuration with custom binding..
    In the bindings -> Endpoint behavior.. try and add the new behavior.. set the desired protection level.

    5. Now, even after this when browsing the app.. you are seeing an error.. 
    It might mean that your application pool has "Enable 32 bit applications" set to False.. Make it true

    this is all is required to get it to sign.

    If you want SSL, one can (this I haven't tested)
    1. configure their IIS application to accept SSL requests.
    2. The endpoint might need to have httpsTransport instead of httpTransport 

    Hope it helps somebody.


    Praveen Behara
    MCST : BizTalk Server 2006 R2, 2010

    • Proposed as answer by Shankycheil Friday, January 24, 2014 7:38 AM
    Friday, January 24, 2014 6:57 AM