Administering, Deploying and Securing BizTalk Server 2004

1
Administering, Deploying and Securing BizTalk
Server 2004

• Scott Woodgate
• Lead Product Manager
• Microsoft E-Business Servers

2
Agenda

• Simplified architecture for development
• Full Production architecture
• Full Secure Scale-Out Architecture
• Performance Preliminaries
• Physical Deployment How-To

3
Basic Architecture
Host
Message Format 2
Business Rules
Message Format 1
Send Port
Orchestration 1
Orchestration 2
Receive Port
Adapter
Adapter
Send Pipeline
Receive Pipeline
Publish and Subscribe Message Box (SQL)
Tracking DB
Config DB DB
4
demo
Basic Architecture Developer Perspective
5
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 13 ratio (dbprocessing)
• Scale out each layer independently

BizTalk Server
n
Independent scale-out
SQL Server
n
6
The simple stuff Database Scale-Out
7
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.

8
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

Activation
Correlation
Master MessageBox
Which MessageBox contains the state?
Round robin
MessageBox 2
MessageBox 1
Orchestration
9
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.

10
demo
MessageBox scale out demo
11
The flexible stuff BizTalk Scale-Out
12
BizTalk Scale concepts Hosts
Host A

• 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 arent scaling together or
  security requirements change
• In the default install for development this is a
  single host

Orchestration 1 Orchestration 2 Example
Orchestration 1 calls Orchestration 2
Host B
Orchestration 3
Host C
File Receive Adapter
Host D
HTTP Receive and Send Adapter Web Services
Receive and Send Adapter Example Orchestration
3 receives through either HTTP or Web Services
13
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 (11)
• By default for development there is a single host
  instance of the single host with all resources
  are added to that host

Machine 1
Host Instance A Host Instance B Host Instance
C Host Instance D
Machine 2
Host Instance A Host Instance C
Machine 3
Host Instance A Host Instance B
14
BizTalk Host concepts

• 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 dont trust code running in the host

15
demo
Host and host instances demo
16
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

17
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

n
n
18
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

19
demo
Adapter Handler demo
20
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

21
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

22
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

BizTalk Server SSO requests
BizTalk Server MASTER SSO Contains Secret key
SSO Database
23
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

BizTalk Server SSO requests
BizTalk Server MASTER SSO Contains Secret key
SSO Database
24
demo
SSO database/back-up walkthrough
25
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)

26
demo
WMI command-line script example Enabling a
receive location
27
Security, Security, Security
28
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 dont turn them off
• For example MSMQT not installed by default

29
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

30
Example Secure Physical Topology
31
Notes Scaled out Secure Topology

• 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

32
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)

33
Security for another day

• Partner Management
• User authentication avoiding denial of service
• Message security
• PKI, S/MIME
• Transport security
• HTTPS

34
Performance

• EARLY BETA NUMBERS
• Messaging gt 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 lt 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.

35
Physical Deployment
36
BizTalk Artifacts

• Developer produces
• Orchestrations
• Pipelines
• Schemas
• Maps
• Rules
• Use abstractions for physical locations
• Built into assemblies for deployment

37
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

38
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

39
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

40
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

41
demo
Application Deployment
42
Next 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.gotdotne
  t.com/scottwoo