View
218
Download
3
Category
Tags:
Preview:
Citation preview
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
Recommended