Understanding Inbound / Outbound Message Security in BizTalk - BTS Bits - Site Home - MSDN Blogs

Understanding Inbound / Outbound Message Security in BizTalk - BTS Bits - Site Home - MSDN Blogs

In the communication and integration world message is core entity. It is principal data carrier. Applications and businesses trade information using messages. BizTalk is content based publish-subscribe engine which facilitates in enterprise application and business-to-business integration. Some of the entities publish messages through BizTalk while other subscribe and consume.

Sometime, message security becomes a critical factor in integration particularly in Financial and Healthcare domains. Architects are interested to insure authenticity of publisher/subscriber entities, integrity of messages and channel security.

BizTalk provides comprehensive end to end security framework for messages within its architectural boundaries. It initiates when message is received by BizTalk over some communication channel and ends when message is delivered to consumer party/channel. Message security during communication channel and with publisher/subscriber party is also vital but I am currently focusing on message security within BizTalk premises. Otherwise also security outside BizTalk architectural boundaries very much depends on security implementation over communication channels and within integration parties.

At high level BizTalk provides following schema for message level security –

1. Inbound Message Security
1. Receive trusted data
2. Authenticate message sender party
2. Outbound Message Security
1. Send out trusted data
3. Trust between processes

Lets Touch Basics

Before we take on each of these cases, let’s touch base some of the fundamentals related to BizTalk runtime and messages.

BizTalk runtime architecture primarily has four major components – Receive Handler, Message Box, Orchestration and Send Handler. Receive handler which is accountable to receive message from channel contains one or more receive locations. Receive location is combination of receive adapter and receive pipeline. Receive pipeline has four stages – Decode, Disassemble, Validate and Resolve Party. Decode and Resolve Party stages in pipeline deals with message security using encryption and digital signature with the help of certificates.

Message Box is publishing area. Message read from channel are published into message box.

Orchestrations execute business logic. They play subscriber as well as publisher role. They acquire subscribed message instance from message box and carry out business processing.

Send handler plays subscriber role. It fetches message from message box and pushes to channel. Send handler is combination of send pipeline and adapter. Send pipeline contains three stages – Preassemble, Assemble and Encode. Encode stage can be configured to encrypt or digitally sign messages.

Receive handlers, orchestrations and send handlers run under some “Host”. “Host” is a logical entity representing BizTalk runtime services which facilitate in operation of these components. “Host” can be mapped to BizTalk physical machine in BizTalk Server Group. This mapping is named “Host Instance”. One host can be mapped to several BizTalk machines and one machine can have more than one hosts mapped. Each “Host Instance” runs under some windows account and this account acts as principle identity (Service Account) of running host instance. This is a mechanism to acquire scalability and availability in BizTalk implementation.

Message Security Marathon

1. Inbound Message Security

Inbound message security spans from the point where message is read from channel to the point where it is published into message box. Inbound message can be secured in two ways – Encryption and Digital Signature. These configurations are done at two stages of receive pipeline – Decode and Resolve Party.

a. Receive trusted data

Authenticity of incoming message can be ensured by encrypting or digitally signing message content. These techniques make sure that verified/trusted messages land in BizTalk architectural boundary. Let’s looks at these technical scenarios one by one.

Assume that some message is received from some integration party/partner.

Using Encryption

- Party sends encrypted message to some transport channel. Encryption is done using an agreed upon public key.

- BizTalk receive handler picks message from channel. Message passes through receive pipeline.

- “Decode” stage of receive pipeline is configured with MIME/SMIME decoder pipeline component. Component uses appropriate private key to decrypt incoming encrypted message.

Note:

o Private Key is stored in “Personal Store” for each service account (windows account) of receive handler host instance.

o To understand “Personal Store”, following is description given in MSDN. Every Windows account (enabled to log on interactively on a computer) holds a personal certificate store by the operating system that only that account can access. BizTalk Server uses the personal certificate stores for each of the host instances service accounts to access the private key certificates to which each service account has access. Only owners of the certificate store can access and maintain their personal certificate stores.

- Decrypted message is further published into message box for required processing.

Using Digital Signature

- Party signs message using private key certificate and send it to appropriate channel.

- BizTalk receive handler picks message from channel using appropriate receive adapter. Message is then passed through receive pipeline.

- In pipeline, MIME/SMIME component has been configured in “Decode” stage to verify signed message. It uses integration partner’s public key to verify digital signature of message.

Note:

o Public Key is stored in “Other People Store” on each computer that has a host instance hosting receive handler.

o MSDN describes “Other People Store” as following - Public key certificates, as their name implies, are public and accessible by anyone with access to the computer on which they are stored. BizTalk Server uses public key certificates to encrypt messages to specific parties and to verify the digital signatures for incoming messages from specific parties.

- Verified message is then published to message box.

b. Authenticate Message Sender Party

Along with message, it is also feasible to verify message sender party. Digital signatures are used for this purpose.

- Party signs message using private key certificate and send it to appropriate channel.

- BizTalk receive handler picks message from channel using appropriate receive adapter. Message then passes through the receive pipeline.

- In pipeline, Component configured at Resolve Party stage verifies identity of the party in the BizTalk system using party’s public key certificate.

Note: Public Key is stored in “Other People Store” on each computer that has a host instance holding receive handler.

- Message is then published to message box.

2. Outbound Message Security

Akin to inbound messages, BizTalk also facilitates in secure data transmission from its premises. Outbound messages can be encrypted/digitally signed to make sure that only authorized parties/partners could consume them.

Using Encryption

- BizTalk send handler subscribes message from message box.

- When message passes through send pipeline, in “Encode” stage, MIME/SMIME Encoder component uses partner’s public key to encrypt outgoing message.

Note: Public Key is stored in “Other People Store” on each computer that has a host instance holding receive handler.

- Encrypted message is then transmitted to channel.

- Consumer party fetches message from channel and uses private key to decrypt its content for further use.

Using Digital Signature

- BizTalk send handler subscribes message from message box.

- In “Encode” stage of pipeline, MIME/SMIME Encoder component uses private key to sign outgoing message.

Note: Private Key is stored in “Personal Store” for each service account (windows account) of receive handler host instance.

- Signed message is then transmitted to channel.

- Consumer party/partner uses public key to verify digital signature of message.

3. 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.

Algorithms and Certificates Supported in BizTalk

- BizTalk Server supports the SHA-1 and MD5 signing algorithms for verifying digital signatures for incoming messages.

- BizTalk Server uses the SHA-1 signing algorithm to sign outbound messages.

- The key exchange systems supported by BizTalk for signature keys are RSA and DSS.

- The signing certificate supported by BizTalk Server is x.509 version 3.

- BizTalk Server supports Data Encryption Standard (DES), 3DES, and RC2 encryption algorithms. Further it supports RSA and Diffie Hellman encryption certificates.

Summary

As per requirement, one or more of these approaches are can be applied in permutation. Developers can also use custom pipelines and adapters to implement custom security demands. This article was more related to out of box message security features of BizTalk. Detailed information related to configuration and developed can be studies from MSDN.