locked
Trusted and Un-Trusted Host RRS feed

  • Question

  • Hello All,

    Although I had enough idea about Trusted and Un-Trusted Host but failed to understand when can we use Trusted and when should we use Un-Trusted and what makes it to prefer always Trusted than the other.

    Kindly take some examples to explain.


    Thank You !! Abhishek Reddy.

    Thursday, May 12, 2016 5:44 AM

Answers

  • To be very frank Abhishek, don't worry too much about this, unless you are using/accessing the SSID/PID context properties from custom BizTalk code.

    Only other thing to bear in mind is if your ReceivePort(s) are NOT marked as No Authentication - again normally don't change this-

    If you change the above to Drop messages, and PID/SSID is blank, your messages will get suspended. Again, no reason to do this-

    If you marked the receive port as Authentication Required, and BizTalk Server obtained a valid PID and resolved it to a known party, the message is then queued to the MessageBox database. If the SSID is blank or the PID is a guest ID, BizTalk Server either discards the message or sends it to the suspended queue (depending on your configuration of the Authentication Required property).

    https://msdn.microsoft.com/en-in/library/aa559539.aspx

    I would request you to read the above article, it explains this nicely.


    Thanks Arindam

    Thursday, May 12, 2016 6:42 AM
    Moderator
  • So message will be authorized if we have a trusted host otherwise Message Box will treat service caller as guest user and will be still processing the message with out any change in response(when compared with Un-Trusted).

    No, there is absolutely no difference in how BizTalk processes the message Trusted vs not Trusted.  Any authorization would take place in the downstream app, if it supports that.

    The only difference is whether or not 1 or 2 Context Properties appear on the Message to store the identity of the caller.  Then you or the downstream app have to actually do something to use them.  That's why I say you will know specifically if you need a Trusted Host since you have created a specific implementation that requires it.  There is nothing automatic about it.

    I have only once encountered an app, I didn't create it, that used Authentication Trusted so it could retrieve user specific credentials from SSO to call some other app.  It was written custom to do this.

    Thursday, May 12, 2016 7:00 AM
    Moderator

All replies

  • Hi Abhishek

    There are different ways BTS can authenticate/identify the Sender of a message. Trusted Hosts are one such mechanism - it's not as widely used as digital signature verification, or Party resolution. So, if you have downstream code that relies on PID and SSIS properties(described below), you would have to mark all Hosts involved in your flow as Trusted (to be able to pass/access these properties).

    Please refer this-

    "The primary purposes of authentication trust are to enable pipelines to resolve to a PID and pass that PID along to consuming services for use in authorization and outbound party resolution, and to enable the transmission of the sender Windows Security ID (SSID) along to consuming services for use in orchestration action authorization."

    https://social.msdn.microsoft.com/Forums/en-US/b7577101-e92c-4679-ba4a-c605d5ad3842/biztalk-hosts-trusted-or-not?forum=biztalkgeneral

    After BizTalk Server receives a message, decrypts and validates the message, and has a valid party ID (PID) and certificate to identity the sender of the message, the MessageBox database is ready to verify the subscriptions that the message matches, and to send this message to other hosts for further processing.

    As a message flows from one process to another, it is often necessary to pass the identity of the original sender of the message to downstream processes for authorization, party resolution, and business logic relating to the sender. However, enabling all hosts to flow this information without some type of security or trust mechanism would greatly increase the need to verify that all user objects and code (for example, orchestrations, adapters, pipeline components, functoids) are trustworthy.

    To provide the means to differentiate the level of trust for user objects and code, BizTalk Server provides Authentication Trust as a property of hosts. When the MessageBox database receives a message from a host that has not been set as authentication trusted, the MessageBox database overwrites the PID with the guest ID, and overwrites the SSID with the service account that the host instance is running as. When a host is marked as authentication trusted, BizTalk enables the host to specify any sender SID (SSID) and any party ID (PID) on messages that it queues to the MessageBox database.

    By specifying which hosts are trusted and which are not, you can define security boundaries in which user objects and code can be trusted or not trusted. That is, user objects and code deployed into hosts that have been set to Authentication Trusted need to be more trustworthy than user objects and code deployed to hosts that have not been set to Authentication Trusted. For more information about how to configure authentication trusted host, see How to Modify Host Properties.

    https://msdn.microsoft.com/en-us/library/aa562062.aspx

    Another great reference to understand this-

    https://blogs.msdn.microsoft.com/brajens/2006/10/08/understanding-inbound-outbound-message-security-in-biztalk/

    Trust Between Processes

    When message is read from channel, receive adapter performs protocol-level authentication of the sender to identify Windows user account that represents the sender of the message. Windows user account is populated in SSID (sender security id) context property of the message. For example if message is posted on HTTP channel using windows authentication then authenticated windows account becomes SSID.

         Hosts in BizTalk can be configured as “Authentication Trusted”.

    If host (under which receive handler is running) is not configured as authentication trusted then message box overwrites SSID with service account of receive handler host and PID with the guest id. SSID and PID are two context level properties of messages.

    If receive handler host is configured as authentication trusted then message box trusts on PID and SSID information of message and leaves it intact. This information can further be consumed to authenticate/authorize original sender of message during processing. In coding, SSID can be read from message system context property.


    Thanks Arindam





    Thursday, May 12, 2016 5:49 AM
    Moderator
  • Hello,

    A key point in regards to trusted and untrusted has to do with how message authentication works. In the topic "Authenticating the Sender of a message", the BTS docs say:

    Authentication Trust.
    If the MessageBox database receives a message from a host that you did not identify as authentication trusted, the MessageBox database will overwrite the PID (Party ID) with the guest ID, and the SSID with the service account that the host instance is running as. BizTalk Server enables hosts identified as authentication trusted to indicate that the sender of a message that the trusted host is queuing to the MessageBox database is an entity other than the trusted host itself. The primary purposes of authentication trust are to enable pipelines to resolve to a PID and pass that PID along to consuming services for use in authorization and outbound party resolution, and to enable the transmission of the sender Windows Security ID (SSID) along to consuming services for use in orchestration action authorization.

    The only tricks here is that you cannot use the same service account or the same group to run hosts that have different authentication trust levels (i.e. can't run a trusted and an untrusted host under the same account).

    So the crust is:

    1) BizTalk Server enables hosts identified as authentication trusted to indicate that the sender of a message that the trusted host is queuing to the MessageBox database is an entity other than the trusted host itself.

    2) The primary purposes of authentication trust are to enable pipelines to resolve to a Product ID (PID) and pass that PID along to consuming services for use in authorization and outbound party resolution, and to enable the transmission of the sender Windows Security ID (SSID) along to consuming services for use in orchestration action authorization.


    Rachit Sikroria (Microsoft Azure MVP)

    Thursday, May 12, 2016 5:56 AM
    Moderator
  • Hi Rachit,

    Thank you for the above.

    • If host (under which receive handler is running) is not configured as authentication trusted then message box overwrites SSID with service account of receive handler host and PID with the guest id. SSID and PID are two context level properties of messages.

    By above statement:

    What are the consequences that are going to take place if it is guest id, will we not able to get the response?

    Will there be any performance issue because of this?



    Thank You !! Abhishek Reddy.

    Thursday, May 12, 2016 6:21 AM
  • Hi Arindam,

    Thank you for the reply.

    If I am using web-services to interact with external down stream system or also may use WCF internally under a same domain which is already a secured environment as our service is not getting exposed to the real world?

    In this case If In use Un-Trusted Host will I be not able to get the responses?as I will be under guest to the message box.

    also will there be any performance issue as it is trying to allow me with a guest account?

    If at all I am able get the same results in both cases then why is it differentiated?  


    Thank You !! Abhishek Reddy.

    Thursday, May 12, 2016 6:26 AM
  • You will probably never need to create a Trusted Host.  I never have.

    So, always make your Hosts not Authentication Trusted unless you know specifically that you need a Trusted Host.  Since you have to do things to make this useful, you will know for sure when you need it.

    The use case for this is when an authenticated client connects to a BizTalk hosted Service and the BizTalk Hosts are allowed to store and retrieve the identity, not credentials, of the caller to pass downstream for authorization, not authentication.

    Thursday, May 12, 2016 6:32 AM
    Moderator
  • Hi John,

    Thank you for letting me know something new on authorization.

    So message will be authorized if we have a trusted host otherwise Message Box will treat service caller as guest user and will be still processing the message with out any change in response(when compared with Un-Trusted).

    Please correct me if my understanding is wrong.


    Thank You !! Abhishek Reddy.

    Thursday, May 12, 2016 6:42 AM
  • To be very frank Abhishek, don't worry too much about this, unless you are using/accessing the SSID/PID context properties from custom BizTalk code.

    Only other thing to bear in mind is if your ReceivePort(s) are NOT marked as No Authentication - again normally don't change this-

    If you change the above to Drop messages, and PID/SSID is blank, your messages will get suspended. Again, no reason to do this-

    If you marked the receive port as Authentication Required, and BizTalk Server obtained a valid PID and resolved it to a known party, the message is then queued to the MessageBox database. If the SSID is blank or the PID is a guest ID, BizTalk Server either discards the message or sends it to the suspended queue (depending on your configuration of the Authentication Required property).

    https://msdn.microsoft.com/en-in/library/aa559539.aspx

    I would request you to read the above article, it explains this nicely.


    Thanks Arindam

    Thursday, May 12, 2016 6:42 AM
    Moderator
  • "In this case If In use Un-Trusted Host will I be not able to get the responses?as I will be under guest to the message box."

    No, you will be able to get response, as described in my post earlier.

    "also will there be any performance issue as it is trying to allow me with a guest account?

    If at all I am able get the same results in both cases then why is it differentiated?"

    Performance will not come into the picture here.

    This is meant for specific cases, like when you want to write your own/custom Party logic in downstream code- again, rarely is this used, if ever. So, don't bother.


    Thanks Arindam





    Thursday, May 12, 2016 6:45 AM
    Moderator
  • Hi Rachit,

    Thank you for the above.

    • If host (under which receive handler is running) is not configured as authentication trusted then message box overwrites SSID with service account of receive handler host and PID with the guest id. SSID and PID are two context level properties of messages.

    By above statement:

    What are the consequences that are going to take place if it is guest id, will we not able to get the response?

    Will there be any performance issue because of this?



    Thank You !! Abhishek Reddy.

    Performance doesn't come to picture here because this setting doesn't impact your business flow. The only case were you will need trusted host is while doing authorization and outbound party resolution. SID and PID are two context level properties of messages that are used to authenticate/authorize original sender of message during processing in BizTalk and the MessageBox database will overwrite the PID (Party ID) with the guest ID, and the SSID with the service account that the host instance is running as if you host is not set to trusted.

    Like I have mentioned before A key point in regards to trusted and untrusted has to do with how message authentication works. The primary purposes of authentication trust are to enable pipelines to resolve to a PID and pass that PID along to consuming services for use in authorization and outbound party resolution, and to enable the transmission of the sender Windows Security ID (SSID) along to consuming services for use in orchestration action authorization.

    So big question is when you should set the Host as trusted?

    If you want a downstream process to know the SSID and PID of the original sender of the message, you must set all hosts that the message passes through as authentication trusted. In addition, in cases such as when the message is received and subsequently used to construct outbound messages in an orchestration, the SSID and PID received on inbound messages must be explicitly added as a property to outbound messages in order to flow these identities.



    Rachit Sikroria (Microsoft Azure MVP)

    Thursday, May 12, 2016 6:47 AM
    Moderator
  • So message will be authorized if we have a trusted host otherwise Message Box will treat service caller as guest user and will be still processing the message with out any change in response(when compared with Un-Trusted).

    No, there is absolutely no difference in how BizTalk processes the message Trusted vs not Trusted.  Any authorization would take place in the downstream app, if it supports that.

    The only difference is whether or not 1 or 2 Context Properties appear on the Message to store the identity of the caller.  Then you or the downstream app have to actually do something to use them.  That's why I say you will know specifically if you need a Trusted Host since you have created a specific implementation that requires it.  There is nothing automatic about it.

    I have only once encountered an app, I didn't create it, that used Authentication Trusted so it could retrieve user specific credentials from SSO to call some other app.  It was written custom to do this.

    Thursday, May 12, 2016 7:00 AM
    Moderator