locked
BizTalk WCF-BasicHttp Transport with Message Credentials- Credential config RRS feed

  • Question

  • Hi,we are exposed BizTalk Schema as a Service in SSL env(i.e.https://abc/abc.service").The call comes from external(customer) via ISA server to BizTalk.Customer sent the following XML request to this service

    Customer is sending Credentials in SOAPHeader and with Request Message.I would like to know that,those credential we need to share to customer or else we have to take it from customer and include in our service web.config value

    Thursday, December 18, 2014 9:28 AM

Answers

  • Hi,

    I have already replied to this question on

    Transport and Message Level Security for BizTalk Exposed WCF Services

    Any ways going ahead with your scenario i am listing your points below

    I am going by each of your question .If I am missing any thing please post back. Ihave altered some of your quires here as per my understating of problem

    1 ) Which binding to Use for security Mode TransportWithMessageCredential.

    Ans .It should be WS-HTTP binding so that user name and password can flow in secure encrypted way .

    2) Do i need to share Windows AD User or Local User can work for Authentication ?

    Ans- Authentication can be done either with your  Windows AD User or system local user . If you are using Local User than  you need to store its configuration value either in cache memory or custom db for validation purpose.

    3)Configuration file look like given below code

    <wsHttpBinding>
    <binding name="WsHttpBindingCustom">
            <security mode="TransportWithMessageCredential" >
               <message clientCredentialType="UserName" />
            </security>
    </binding>
    </wsHttpBinding>

    Note : All the WCF Service configuration can be applied through Biz Talk only one thing you need to do is to explore  the Possibility. 

    You can find good Articles in below links

     MSDN Message and Transport Security

    How to: Use Transport Security and Message Credentials

    Below is the C# function you need to consider which is acting as your security Activation token

                //Get an XmlDictionaryReader to read the header content
                //******************************************************************************************
                int header1 = operationContext.RequestContext.RequestMessage.Headers.FindHeader("InputValue1",
                    "http://sampleNameSpace");
                int header2 = operationContext.RequestContext.RequestMessage.Headers.FindHeader("InputValue2",
                    "http://sampleNameSpace");
    
                XmlDictionaryReader reader = operationContext.RequestContext.RequestMessage.Headers.GetReaderAtHeader(header1);
                string header1Value = reader.ReadElementString();
                reader = operationContext.RequestContext.RequestMessage.Headers.GetReaderAtHeader(header2);
                string header2Value = reader.ReadElementString();

    And certain modification in the machine.config file for Custom behavior. These changes are specific to solution and I don't think pre build MSI can help you in this .

    You could try replacing the schema and work with your own custom behavior . There are certain changes in Machine.config file as well to populate your custom behaviour .

          <system.serviceModel>
                <extensions>
                      <behaviorExtensions>
                            <add name="WCFCustomBehaviorExtension" type="Microsoft.Samples.BizTalk.Adapters.WCFCustomBehaviorExtClass.BizTalkWCFBehaviorExtensionElement, WCFCustomBehaviorExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=38d724c20be5198f"/>
                      </behaviorExtensions>
                </extensions>
          </system.serviceModel>

    All have been well described over MSDN and Polo

    Using Custom Behaviors with the BizTalk WCF Adapters, Part 1

    Using Custom Behaviors with the BizTalk WCF Adapters, Part 2

    Thanks

    Abhishek




    Sunday, January 4, 2015 2:42 AM
  • Hi BizQ,

    If you have shared the credentials  - UID and PWD and not Windows account, then you need to have custom WCF behaviour to access the credentials from the data store validate identities of the caller and pass the message on if it is successful.

    When using the custom behaviour, when a message is received by the WCF-Custom adapter, and the custom authentication check is passed in the WCF custom behavior, the message is published to the MessageBox database.

    Here the data store where the credentials will be stored could be custom database, SSO db or any config file (sometime also a custom property pages of the WCF behavior tab).

    By default WCF uses Windows to validate the user name and password. Even when you use “Windows” or “UserName” for “Message client credential type” property in the security tab of the WCF adapters. When you use this the above properties, you must create the domain or local user accounts corresponding to client credentials.  Reference:  MSDN: WCF-WSHttp Transport Properties Dialog Box, Receive, Security Tab http://msdn.microsoft.com/en-us/library/bb226411.aspx.

    If you have got the idea of use the above mentioned configurations from my reply to another forum question, then as said the “UserName” configuration is to have https+message/payload level authentication against the windows group. For your requirement of custom credentials you need to have WCF extension in the form of custom behavior.

    So for your requirement where you’re not using the Windows account, you need to use WCF custom behavior.

    Check the following link for sample on development custom behaviour for WCF ports. And the sample provided here

    http://go.microsoft.com/fwlink/?LinkId=139693

    Following are official wording from Microsoft on this context:

    By configuring a WCF adapter to use a WCF custom behavior, the behavior functionality will be invoked when the call comes into the BizTalk adapter. If the behavior’s processing of the message does not result in a positive response, the message is not allowed to be posted to a receive location. The message thus gets rejected at the transport level and is not preserved. For instance, you could check the identity of the caller posting the message to the BizTalk receive location against a list of allowed groups. The administrator can configure the group names in the property pages of the WCF behavior tab. The behavior custom code can read those groups and check access against the groups with which the identity is associated. The identity of the logged-in user is sent as part of the WCF call in the SOAP headers. That identity can be authenticated at either the transport layer or the message layer depending on the configuration. If that identity is in one of the allowed groups, the call is allowed to pass through to the receive location.

    Reference: http://msdn.microsoft.com/en-us/library/cc952299(v=bts.10).aspx

    “WCF custom behaviour are used …..to validate identities of the caller and pass the message on if it is successful, and so on. It is truly a custom processing mechanism, so you can implement whatever extensibility you feel your application needs

    Reference: http://msdn.microsoft.com/en-US/library/cc952299(v=bts.10).aspx


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    • Marked as answer by Angie Xu Wednesday, January 7, 2015 11:48 AM
    Sunday, January 4, 2015 1:18 AM

All replies

  • As BizTalk is service provider I would suggest to share your own SOAP Header credential to the client  and validate the request once it coms to BizTalk . Vice Versa will also work but I would prefer the let subscriber decide the authentication instead of Client . And in your case BizTalk is a service subscriber.

    Thanks

    Abhishek

    • Proposed as answer by Abhishek0127[Abhishek kumar]MVP Friday, December 19, 2014 4:15 PM
    • Marked as answer by Angie Xu Thursday, December 25, 2014 2:11 AM
    • Unmarked as answer by BizQ Saturday, January 3, 2015 2:58 AM
    Thursday, December 18, 2014 9:42 AM
  • BizQ,

    Client is going to access your service and the published message would come to your BizTalk server, so you (Service provider) do the authentication and provide the credentials which you have more control over. This could be credentials from Active directory in your end or custom credentials stored in your custom database at your end.


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, December 18, 2014 2:19 PM
  • I would like to know that,those credential we need to share to customer or else we have to take it from customer and include in our service web.config value-> You need to provide them user ID and password because your service is going to validate the client.

    As I understand the purpose of using the username/password is validate (authenticate/authorize) the client to get access of your service. Now How the client is going to be authenticated ?

    Option-A – Using your Domain or Windows based , If you just want to authenticate then you do not need any custom behaviour however if you want to check if the user is present in a particular AD group you need to write your custom behaviour.

    Option B- You can store user ID and password for every client in a database and authenticate them in your custom Behaviour.

    There is a great blog post by Paolo, Have a read, you will find everything you need

    Customizing and Extending the BizTalk WCF Adapters

    Also this is again a good blog post on something similar

    http://www.stuartcharles.co.uk/securing-a-wcf-service-in-biztalk-by-roleclaim-using-windows-or-claims-based-authentication/

    There are two things

    WCF Service – You do not need anything here except of following

    1-    Anonymous Access on the service

    2-    AppPool- To send the message to BizTalk MessageBox

    3-    Certificates on your IIS- since you are using Transport.

    BizTalk WCF Adapter( You would eventually end up using WCF-CustomIsolated)- In this case you write a custom behaviour and use it for Option A or Option B.

    I have implemented similar case using guidelines from Paolo’s blog. Hope this helps.


    Greetings,HTH
    Naushad Alam

    When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer
    alamnaushad.wordpress.com

    Thursday, December 18, 2014 4:41 PM
    Moderator

  • The user has already mentioned that request are being validated depending on the SOAP Header which is part of Biz Talk exposed Schema .  Here the requirement is to know were he can store the SOAP Header credential .

    Will it be Biz Talk who will share the SOAP header details to the client or Client will share his Header details so that Biz Talk can validate .

    As I have already mentioned in my above post It is always preferred to store configuration details with the subscriber . And in current scenario BizTalk is being used as a subscriber and thus it would be best idea to store the configuration details in BizTalk  which may be either in BTSNTSVc.exe.config file ,SSO or some custom DB.

    Thanks

    Abhishek

    Thursday, December 18, 2014 4:53 PM
  • As per your suggestion I shared custom UID and PWD (not Windows UserID) to customer to include in SOAP Header.Now 

    in Adapter configuration I set Transport Type: WCF-CustomIsoated
    Binding Type: wsHTTPBinding  and “Security” = Message and ClientCredentailType = “UserName”.

    I got little bit confused Where do i have to configure my custom credentials. is it in Service Web.config file?
    or SSO config Store or Custom DB.please need your suggestion

    Saturday, January 3, 2015 2:05 AM
  • Hi BiZQ,

    It has been well described in Richard Seroter Security pattern , you custom database to store(backed repository) the local user ID and password which you can share with End user to do the authentication .

    However there is a pointer here  as in this ,WCF forces you to utilize a secure channel (HTTPS) so that the credentials aren’t passed in the clear.

    Notice that TransportWithMessageCredential is set, indicating that the HTTPS channel is being used. The “message client credential type” is set to “Username”, which then allows the user to edit the “user name credentials” value.

    We is the past have tried with custom repository Database and it worked fine for authentication you can also

    go ahead with custom repository .

    Will also suggest to to go through Richard seroter link

    BizTalk and WCF: Part II, Security Patterns

    Thanks

    Abhishek

    Saturday, January 3, 2015 4:39 AM
  • Hi BizQ,

    If you have shared the credentials  - UID and PWD and not Windows account, then you need to have custom WCF behaviour to access the credentials from the data store validate identities of the caller and pass the message on if it is successful.

    When using the custom behaviour, when a message is received by the WCF-Custom adapter, and the custom authentication check is passed in the WCF custom behavior, the message is published to the MessageBox database.

    Here the data store where the credentials will be stored could be custom database, SSO db or any config file (sometime also a custom property pages of the WCF behavior tab).

    By default WCF uses Windows to validate the user name and password. Even when you use “Windows” or “UserName” for “Message client credential type” property in the security tab of the WCF adapters. When you use this the above properties, you must create the domain or local user accounts corresponding to client credentials.  Reference:  MSDN: WCF-WSHttp Transport Properties Dialog Box, Receive, Security Tab http://msdn.microsoft.com/en-us/library/bb226411.aspx.

    If you have got the idea of use the above mentioned configurations from my reply to another forum question, then as said the “UserName” configuration is to have https+message/payload level authentication against the windows group. For your requirement of custom credentials you need to have WCF extension in the form of custom behavior.

    So for your requirement where you’re not using the Windows account, you need to use WCF custom behavior.

    Check the following link for sample on development custom behaviour for WCF ports. And the sample provided here

    http://go.microsoft.com/fwlink/?LinkId=139693

    Following are official wording from Microsoft on this context:

    By configuring a WCF adapter to use a WCF custom behavior, the behavior functionality will be invoked when the call comes into the BizTalk adapter. If the behavior’s processing of the message does not result in a positive response, the message is not allowed to be posted to a receive location. The message thus gets rejected at the transport level and is not preserved. For instance, you could check the identity of the caller posting the message to the BizTalk receive location against a list of allowed groups. The administrator can configure the group names in the property pages of the WCF behavior tab. The behavior custom code can read those groups and check access against the groups with which the identity is associated. The identity of the logged-in user is sent as part of the WCF call in the SOAP headers. That identity can be authenticated at either the transport layer or the message layer depending on the configuration. If that identity is in one of the allowed groups, the call is allowed to pass through to the receive location.

    Reference: http://msdn.microsoft.com/en-us/library/cc952299(v=bts.10).aspx

    “WCF custom behaviour are used …..to validate identities of the caller and pass the message on if it is successful, and so on. It is truly a custom processing mechanism, so you can implement whatever extensibility you feel your application needs

    Reference: http://msdn.microsoft.com/en-US/library/cc952299(v=bts.10).aspx


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    • Marked as answer by Angie Xu Wednesday, January 7, 2015 11:48 AM
    Sunday, January 4, 2015 1:18 AM
  • Hi,

    I have already replied to this question on

    Transport and Message Level Security for BizTalk Exposed WCF Services

    Any ways going ahead with your scenario i am listing your points below

    I am going by each of your question .If I am missing any thing please post back. Ihave altered some of your quires here as per my understating of problem

    1 ) Which binding to Use for security Mode TransportWithMessageCredential.

    Ans .It should be WS-HTTP binding so that user name and password can flow in secure encrypted way .

    2) Do i need to share Windows AD User or Local User can work for Authentication ?

    Ans- Authentication can be done either with your  Windows AD User or system local user . If you are using Local User than  you need to store its configuration value either in cache memory or custom db for validation purpose.

    3)Configuration file look like given below code

    <wsHttpBinding>
    <binding name="WsHttpBindingCustom">
            <security mode="TransportWithMessageCredential" >
               <message clientCredentialType="UserName" />
            </security>
    </binding>
    </wsHttpBinding>

    Note : All the WCF Service configuration can be applied through Biz Talk only one thing you need to do is to explore  the Possibility. 

    You can find good Articles in below links

     MSDN Message and Transport Security

    How to: Use Transport Security and Message Credentials

    Below is the C# function you need to consider which is acting as your security Activation token

                //Get an XmlDictionaryReader to read the header content
                //******************************************************************************************
                int header1 = operationContext.RequestContext.RequestMessage.Headers.FindHeader("InputValue1",
                    "http://sampleNameSpace");
                int header2 = operationContext.RequestContext.RequestMessage.Headers.FindHeader("InputValue2",
                    "http://sampleNameSpace");
    
                XmlDictionaryReader reader = operationContext.RequestContext.RequestMessage.Headers.GetReaderAtHeader(header1);
                string header1Value = reader.ReadElementString();
                reader = operationContext.RequestContext.RequestMessage.Headers.GetReaderAtHeader(header2);
                string header2Value = reader.ReadElementString();

    And certain modification in the machine.config file for Custom behavior. These changes are specific to solution and I don't think pre build MSI can help you in this .

    You could try replacing the schema and work with your own custom behavior . There are certain changes in Machine.config file as well to populate your custom behaviour .

          <system.serviceModel>
                <extensions>
                      <behaviorExtensions>
                            <add name="WCFCustomBehaviorExtension" type="Microsoft.Samples.BizTalk.Adapters.WCFCustomBehaviorExtClass.BizTalkWCFBehaviorExtensionElement, WCFCustomBehaviorExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=38d724c20be5198f"/>
                      </behaviorExtensions>
                </extensions>
          </system.serviceModel>

    All have been well described over MSDN and Polo

    Using Custom Behaviors with the BizTalk WCF Adapters, Part 1

    Using Custom Behaviors with the BizTalk WCF Adapters, Part 2

    Thanks

    Abhishek




    Sunday, January 4, 2015 2:42 AM