Administering, Deploying and Administering, Deploying and Securing BizTalk Server 2004Securing BizTalk Server 2004

Scott WoodgateScott Woodgate

Lead Product ManagerLead Product Manager

Microsoft E-Business ServersMicrosoft E-Business Servers

Agenda

• Simplified architecture for development

• Full Production architecture

• Full Secure Scale-Out Architecture

• Performance Preliminaries

• Physical Deployment How-To

Basic Architecture

AdapterAdapter

HostHostO

rch

estr

atio

n #

1O

rch

estr

atio

n #

1

Orc

hes

trat

ion

#2

Orc

hes

trat

ion

#2

Receive PortReceive Port Send PortSend Port

TrackingTrackingDBDB

Config DBConfig DBDBDB

AdapterAdapter

Receive PipelineReceive Pipeline

Business Business RulesRules

Send PipelineSend Pipeline

Publish and SubscribePublish and SubscribeMessage Box (SQL)Message Box (SQL)

Message Format 1Message Format 1Message Format 2Message Format 2

Basic Architecture Basic Architecture Developer PerspectiveDeveloper Perspective

demodemo

Scale-Out Requirements

• Multiple BizTalk Servers• Processing• CPU threshold

• Partition processing work into “containers”

• Similar/Different security requirements

• Multiple SQL Servers• Database• Lock contention/CPU

threshold• Approx 1:3 ratio

(db:processing)• Scale out each layer

independently

BizTalk BizTalk ServerServer

SQL SQL ServerServer

nn

nn

Independent scale-outIndependent scale-out

The simple stuff: The simple stuff: Database Scale-OutDatabase Scale-Out

Core SQL Databases

• BizTalkMsgBoxDb: “MessageBox”• High traffic volume read/write intensive

• BizTalkMgmtDb: Configuration• Low traffic volume read in production• Writes for EDI and BTF2.0 acks

• BizTalkDTADb: Tracking• High traffic volume writes in production• Low traffic volume reads in production

• SSODB: Single-Sign On• Low traffic volume reads in production• Low traffic volume writes in production

• These databases are almost always used and can be placed in separate SQL machines depending on traffic requirements.

MessageBox scale-out/fault tolerant model

• Master MessageBox• Routes incoming message• Activation: Round-robin• Correlation: Route to

messagebox containing persisted state

• Scaled out MessageBoxes• Process messages• Persist orchestration state

• Databases are the only state container

• ALL Databases should be MSCS clustered for fault tolerance

MasterMasterMessageBoxMessageBox

MessageBox 2MessageBox 2MessageBox 1MessageBox 1

ActivationActivationCorrelationCorrelation

Which MessageBox Which MessageBox contains the state?contains the state?

Round robinRound robin

OrchestrationOrchestration

Feature specific SQL Databases

• BAMArchive, BAMStarSchema, BAMPrimaryImport: BAM

• May be high traffic volume if using BAM• BizTalkHWSDb: Human Workflow

• May be high traffic volume if using HWS• BizTalkRulesEngine: Rules Engine

• May be high traffic if using rules engine• These databases are used dependent on

features used and can be placed on separate SQL machines dependent on traffic requirements.

demodemo

MessageBox scale out MessageBox scale out demodemo

The flexible stuff: The flexible stuff: BizTalk Scale-OutBizTalk Scale-Out

BizTalk Scale concepts: Hosts• A host is a logical container for

BizTalk Server resources such as orchestrations, receive and send adapters

• Why have hosts?• Hosts provide resource partitioning• Hosts provide security partitioning

• What do I put in a single host?• Resources that scale together and

have the same security requirements

• When do I move resources out of a particular host?

• When the resources aren’t scaling together or security requirements change

• In the default install for development this is a single host

Host “A”Host “A”

Host “C”Host “C”

Orchestration #1Orchestration #1Orchestration #2Orchestration #2

Example: Orchestration #1 Example: Orchestration #1 calls Orchestration #2calls Orchestration #2

File Receive AdapterFile Receive Adapter

Host “D”Host “D”HTTP Receive and Send HTTP Receive and Send

AdapterAdapter

Web Services Receive and Web Services Receive and Send AdapterSend Adapter

Example: Orchestration #3 receives Example: Orchestration #3 receives through either HTTP or Web Servicesthrough either HTTP or Web Services

Host “B”Host “B”

Orchestration #3Orchestration #3

BizTalk Scale concepts: Host Instances

• A host instance is a physical instance of a logical host on a single machine

• Why have host instances?• Create a single container and

scale it out easily by creating new instances

• One host can have many instances (1: many)

• One machine may only run a single host instance of a particular host (1:1)

• By default for development there is a single host instance of the single host with all resources are added to that host

Machine “1”Machine “1”

Machine “3”Machine “3”

Host Instance AHost Instance AHost Instance BHost Instance BHost Instance CHost Instance CHost Instance DHost Instance D

Host Instance AHost Instance AHost Instance BHost Instance B

Machine “2”Machine “2”

Host Instance AHost Instance AHost Instance CHost Instance C

• In-Process Host Instances• Physical concept: Instantiated Host Instances are created as physical

Windows Services running under a user name and password• BizTalk Server controls these processes They are the BizTalk Server

processes hence “in-process”• Can start, stop

• Isolated Host Instances• Abstract concept: Instantiated Isolated Hosts run out of process of BizTalk

Server. No new service is created. For example aspnet runs in an isolated host as it has its own service

• BizTalk Server can not control these processes• Creating an Isolated Hosts Instance containing resources, such as

adapters, gives the process permissions to submit a message to BizTalk Server

• Authentication Trusted• This host will pass the message sender context through the system. • Example: Ford submitted a message to the system. The message will

continue to be identified as from Ford.• Non-Authentication Trusted

• This host will normalize the sender of the message to “guest”• Example: You don’t trust code running in the host

BizTalk Host concepts

demodemo

Host and host Host and host instances demoinstances demo

Example: Multiple Orchestration Host Instances

• Scenario: Message comes in for Orchestration #1 part of Host Instance “A”

• Which Machine executes it?• Machine “1”, “2” or “3” depending on

availability.• For this example machine “1”, host

“A” executes the orchestration• Half-way through the orchestration

sends out a message and persists state to the messagebox waiting for a responses

• There is no affinity to host instance once dehydrated. The response message comes back and depending on availibility any of “1”, “2” or “3” can execute the orchestration

Machine “1”Machine “1”

Host Instance AHost Instance AHost Instance BHost Instance BHost Instance CHost Instance CHost Instance DHost Instance D

Machine “3”Machine “3”

Host Instance AHost Instance AHost Instance BHost Instance B

Machine “2”Machine “2”

Host Instance AHost Instance AHost Instance CHost Instance C

Example: Adapter Scale-Out• Adapters have two parts that can scale

independently:• Receive side called the receive handler• Send side called the send handler

• Why scale independently?• Traffic differences• Example: Receive 100 messages

process them Send back 500 messages• Fully fault tolerant if there are two host

instances running a specific adapter receive or send handler

• Receive handler can be installed in: multiple hosts and instantiated on their multiple host instances not for scale-out but for differing traffic requirements (eg. Inside firewall web services and outside firewall web service)

• Send handler for this version is restricted to one host per adapter an its multiple host instances

• This scale-out gives you the ability to minimize the adapters installed to the machines that need them

nn

Host “A”Host “A”

File Receive AdapterFile Receive Adapter

HostHost Instance Instance

““A”A”

Host “B”Host “B”

File Receive AdapterFile Receive Adapter

HostHost Instance Instance

““B”B”

nn

Host “C”Host “C”

File Send AdapterFile Send Adapter

HostHost Instance Instance

““C”C”

Adapter Specific Scale-Out Behaviours

• How an adapter behaves when there are two receive handlers pointing to a location is adapter specific

• HTTP/S, Web Services• Use NLB through WLBS • Scales out (both receive at once round-robin)• Fault tolerant• Run as Isolated Hosts

• File: • Use UNC path• Scales out (both receive at once round-robin)• Fault tolerant• Requires registry work (Rename function)• In-Process

• BizTalk Message Queuing• Use NLB through WLBS• Fault tolerant• No scale-out, one MSMQT instance at a time can service a single queue due to “in-order”

messaging support for this transport• In-Process

• Custom Adapter• Adapter dependent• In-Process or Isolated

• The above rules apply for both the send handler and the receive handler

demodemo

Adapter Handler demoAdapter Handler demo

Example: Simple (Yes Simple) Scale-Out

Scenario: Receive a message from a trading partner through web services, execute a business process that sends the message to SAP

• Hosts • A: Web Services Receive Adapter Handler• B: Orchestration• C: SAP Send Adapter Handler

• Host Instance• A on Machine 1• B on Machine 2• C on Machine 3

• Advantages:• Minimize adapter installs to machines that need them ($)• Independently scale out receive from send and orchestration• Hosts are scale invariant, keep the same three hosts and add host

instances

Built in Services 1: Tracking• The tracking service writes

tracking information to the tracking database

• The tracking service runtime runs in a host like the other artifacts

• My default “tracking” is in the default host

• The most secure installation has tracking in a dedicated host so no user-code is inside the process

• Create a new host and select “Tracking”

• An aside (unrelated to tracking): The certificate is used for inbound decryption of incoming messages

Built-in Services 2: Single Sign On• Even if you are not using SSO

capabilities directly BizTalk Server leverages SSO for URL information as it provides a secure store

• SSO does not run in a host it has its own windows service

• SSO designed to minimize attack surface with only one machine per farm containing the key

• Master Key is used for encryption and resides on Master SSO server

• It is CRITICAL that you back-up your SSO master key

• \Program Files\Common Files\Enterprise Single Sign-On

• SSOConfig.exe –backupsecret myfile

SSOSSODatabaseDatabase

BizTalk BizTalk ServerServer

MASTER SSOMASTER SSOContainsContains

Secret keySecret key

BizTalk BizTalk ServerServerSSO SSO

requestsrequests

Single Sign-on Fault-Tolerance• What if the power-supply in the

Master SSO Machine blows up?• Scenario A: Slave machines cache

the information they need in memory and runtime will continue but:

• NO changes to ports or SSO configuration

• Convert a slave machine to a master with the backup-key to restore complete functionality

• Scenario B: MSCS Cluster the SSO service

• Which do I choose?• Scenario A will be suitable for most

customers and is consistent with adapter and orchestration scale out

SSOSSODatabaseDatabase

BizTalk BizTalk ServerServer

MASTER SSOMASTER SSOContainsContains

Secret keySecret key

BizTalk BizTalk ServerServerSSO SSO

requestsrequests

demodemo

SSO database/back-up SSO database/back-up walkthroughwalkthrough

BizTalk Administrator Tools

• MMC Snap-in for Administering BizTalk• Scaling

• Creates new message boxes

• Defines Hosts and enlists applications

• Enrolls new Servers as Host Instances

• Operations• Start / Stop Orchestrations

• Enable / Disable Receive Locations

• WMI and ExplorerOM command-line scripting

• Deployment tool (more on this later)

Security, Security, Security, Security, SecuritySecurity

Security Hardening

• Secure by design:• threat modeling, security design reviews• code quality tools, secure coding guidelines, code

reviews, security bug bashes• MS employed ethical hackers to harden the

product

• Secure by default:• running with least privilege, reducing attack

surface• Turn on the dials to use them don’t turn them off• For example MSMQT not installed by default

Quick Revision: Hosts and Security

• Run each host in its own security account• Isolates each host from seeing outside data

• Ability to trust or not trust hosts to identify partners

• Isolated hosts prevent untrusted code from impacting other applications

• For example if IIS/ASP.NET was comprised BizTalk Server will not be as it is an isolated host

Example: Secure Physical Topology

INTERNET

FirewallIIS SMTP RAS

Firewall

Firewall

DC-0

FirewallCorpnet

redmond\joe

REDMOND

No BizTalk bits in DMZ!

MSG-

BOXHAT Admin DC-3 SSO

Rules

ONLY TS-access to Admin box

Receiving Logic

HAT/Admin

SSO

Tracking

DC-2Orchestration/SSO

Orchestration/MSMQT

DC-1

One-way trusts

No route from DMZ

• This is an example, not the example• Active Directory based (domain users, groups)• Domains enforce trust boundaries• Least privilege accounts (most distributed)• Locked down platform configuration• Minimal custom setup on each box• Centralized administration• No BizTalk bits in DMZ• No trust with DMZ (assumed)• Windows authentication everywhere• N.B. Domains were used for “hard” isolation boundaries but

we do expect customers to run services and orchestration in the middle tier using VLANs to segregate at the network level

Notes: Scaled out Secure Topology

Role based security

• All tools and runtime work against SQL Roles• Message Boxes

• Configuration Database

• Tracking Database …

• Specify Windows Group for each DB during setup• BizTalk Server Administrators (default)

• Isolate user by specifying a different group for each database

• Message Box (runtime and operations)

• Configuration Database (config only)

• Tracking Database (historical data)

Security – for another day

• Partner Management• User authentication avoiding denial of

service

• Message security• PKI, S/MIME

• Transport security• HTTPS

Performance

• EARLY “BETA” NUMBERS• “Messaging” >= BTS2002

• 1 msgbox/3 processing machines = 130msg/sec• 4 msgboxes/10 processing machines = 600msg/sec

• “Orchestration” 5x faster • 1 msgbox/3 processing machines = 200msg/sec

• Request/Reply: < 1sec• 1 msgbox/4 processing machines = 170 msg/sec• Subsecond latency• Out of box the maximum latency introduced by the

messagebox in the polling cycle is 500 ms per message hop within the messagebox and this number is set in BiztalkMgmtDb..adm_ServiceClass table (column MaxReceiveInterval). You may reduce it to a non-zero value for more aggressive polling.

Physical DeploymentPhysical Deployment

BizTalk Artifacts

• Developer produces• Orchestrations

• Pipelines

• Schemas

• Maps

• Rules

• Use abstractions for physical locations

• Built into assemblies for deployment

Deploying Applications

• Get the bits on the box• Deploy assemblies

• Configure the environment• Map the developer logical to the real world

environment

• Configure Relationships• Send/Receive Ports, Partners, Roles

BizTalk Explorer

• Defines the deployment topology

• Integrated with Visual Studio

• UI for defining physical environment• Maps logical Orchestration ports to physical

locations

• Maps applications to Hosts

Deployment Wizard

• GACs and registers assemblies

• Export config created by Explorer• Modify to stage from test to production

• Import on production server

• Import capability to batch config• XML based script

• Configure entire solution with one file

• Add and configure new partners

One-Click Deployment with BizTalk Installer

• BizTalk specific VS Setup project• Custom Action DLL tailored to BizTalk

• Auto-packages BizTalk project output • Point-n-click to add your projects• Updates MSI package with every build

• Imports configuration scripts• Extensible

• All standard setup capabilities• Include your assemblies• Write your own custom actions

Application Application DeploymentDeployment

demodemo

Next StepsNext Steps

• Start building with the BizTalk Server 2004 beta

• Come to my session tomorrow

• Check on the BizTalk Server 2004 overview whitepaper by David Chappell http://blogs.gotdotnet.com/scottwoo