Download Security - Center

Architecture Track
Session 2
Designing Enterprise
Applications for
Microsoft Windows
Server 2003
®
Jason McConnell
®
Audience
Application architects, developers, and
infrastructure professionals
Responsible for designing, developing,
and/or managing enterprise systems
Building applications to take advantage of
Windows Server 2003
Interested in Microsoft technical position
on application architecture
Interested in building applications for a
service-oriented architecture (SOA)
Realistic Expectations
Architecture is a complex domain with
multiple perspectives and many viewpoints.
This track strives to address a small subset.
By no means is it comprehensive in its coverage.
Technical resources are available for many
of the areas not covered today.
A detailed white paper accompanies this track.
Event DVD
MSDN® .NET Architecture Center
Microsoft patterns & practices Web site
Discussion and starting point for further
investigation
Session Objectives
Examine security from the standpoint
of how it impacts the architecture of
an application.
Review the impact of advanced
®
Microsoft .NET caching capabilities.
Discuss reliability and scalability.
Review data access methodologies.
Discuss planning for transaction
management.
Session Agenda
Services
Security
State and transaction management
Availability and scalability
Building Services:
Design Considerations
Partitioning and establishing boundaries
Trust / security
Transactions and state
Availability and scalability
Orders
Credit authorization
Supplier
Security
Establishing and enforcing trust boundaries
Key areas
Authentication
Authorization
Secure communications
Security
Communication
Operation
management
Security
Authentication
Authorization
Data
Secure
communication
Auditing
Business
Profile
management
Presentation
Trustworthy design
Authentication
Custom or platform?
Authorization
Common infrastructure and management
Operations coupling
AD
Other
Secure communication
Intra-application
Inter-service
Auditing
Preserving identity
Profile management
Federation, scalability
AD
Kerberos
Kerberos
Certificates
SSL
WS-Security
Designing for Security
Trust
boundaries
enforced by
authentication
Secure communication
between services and
within application
Users
UI components
Authorizing
actions at the
right granularity
UI process components
Service interfaces
Business
workflows
Business
components
Data access components
Data
sources
Business
entities
Service agents
Services
Trust
boundaries
enforced by
authentication
Using caller
impersonation or
service accounts
at boundaries for
outgoing calls
Security
Authentication
IIS
ASP.
NET
Anonymous
Forms
authentication authentication
Microsoft® SQL Server™
authentication
Where will authentication occur?
Microsoft Internet Information Server (IIS)
for intranet applications
Forms-based authentication within
Microsoft® ASP.NET
Microsoft .NET Passport
authentication
®
Security
Authorization
IIS
NTFS
permissions
(authorization)
ASP.
NET
File authorization
URL authorization
.NET roles
(authorization)
User-defined role
(authorization)
Role-based ASP.NET
Compatible with both forms and
.NET Passport
Generic and Windows objects available
Customizable with IPrincipal and IIdentity
Security
Database Authorization
Web or Application Server
A
B
C
D
E
Role 1
Role 2
Role Mapping
Database Server
Trusted Identity 1
Trusted Identity 2
Identity 1 has read permissions
Identity 2 has read / write permissions
Trust Boundary
Role-based ASP.NET
SQL Server user-defined database roles
SQL Server application roles
Security
Two-tier Scenario
SSL
(privacy / integrity)
ASP.NET
(process identity)
File authorization
NTFS
URL authorization
permissions
.NET roles
(authorization) (authorization)
IIS
User-defined role
(authorization)
ASP.
NET
Anonymous
Forms
authentication authentication
SQL Server
authentication
IPSec
(privacy / integrity)
SSL used for secure WAN
Firewall + IPSec used for LAN
Security
Internet Security Solutions
Baseline Internet Architecture
.NET forms-based authentication
IPrincipal role-based authorization
SSL and IPSec
Two-tiered model has limited database
authentication options.
Security
Application Server Security
More robust, adaptable, scalable
Tiers are loosely coupled via SOAP and
other Internet protocols.
Additional security available:
Microsoft® Active Directory® - based
authentication and roles, and AuthzMan.
Additional scalability via physical tier.
Security with Application Server
Deployment with Three Tiers
NTFS
URL authorization
permissions
(authorization)
(authorization)
IIS
ASP.NET Integrated Windows
(process
(authentication)
identity) require SSL (privacy
Windows
/ integrity)
(authentication)
ASP.
NET
ASP
.NET
IIS
(Web
services
façade)
Web server
Anonymous
authentication
Forms
authentication
Enterprise
Services server
application
dllhost.exe
IPSec
(privacy /
integrity)
SSL
(privacy /
RPC packet
privacy
integrity)
(Authentication)
Application server
ES process
identity
Database
server
IPSec
(privacy /
integrity)
User-defined
database roles
(authentication)
Windows
(authentication)
Summary Recommendations:
Security
Make use of the guidance available in
“Building Secure ASP.NET Applications”.
Make use of Service Accounts when user
identity isn’t needed for database access.
Make use of enhanced security and Active
Directory within the business layer.
Use the Authorization Manager for advanced
authorization features.
Best practices available:
“Building Secure ASP.NET Applications”
http:// msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp
Session Agenda
Services
Security
State and transaction management
Availability and scalability
Challenges in ServiceOriented Architecture (SOA)
Services encapsulate all state management.
Talk via messages over unreliable protocols.
Challenges:
Maintaining conversation state
Managing transactions
Managing concurrent access to data
Caching of data for performance, scalability, and
availability
State and Transactions
Web user state
management
Users
Session state
management
Business
workflows
UI process components
Service interfaces
Business
components
Data access components
Data
Sources
Business
entities
Caching for
ASP.NET
pages and
Web services
Service agents
Services
Security
State for
conversations
between
services
Operational
management
Communication
UI components
Caching across
all tiers
Message-based Communications
Messages are business documents
exchanged to execute a business
process.
Services may expect other services to
remember conversations.
Example: purchase customer ID
A message-based conversation
requires state to be kept and rehydrated as needed for business
operations.
Just like a conversation between people
Conversation State
Isolate conversation state management in
business workflows.
Not in business database or service interface
Microsoft® BizTalk® Server schedules
Keep business components stateless.
Finer business activities
Assume messages can be lost or can
arrive twice.
Unless you have a transactional S & F protocol
SOAP in MSMQ 3.0 over HTTP
WS-Reliability long-term vision
Transaction Management
Services are boundary around state.
Services interoperate through business transactions.
Business transaction <> commit/rollback
Not ACID!
Business transactions are better suited for messagebased systems.
ACID transaction boundary
Committed
Rollback
Business conversation boundary
Order confirmed
Order cancelled—cancellation fee
Cancel order
Cancel delivery
(“Compensation” messages and business logic)
Transaction Model
DTC
Workflow Biz comp
DAL
Business workflows
implement business
processes.
Atomic transaction
Finer-grained business
components initiate
and manage atomic
transactions.
Transactional resource
managers participate
in atomic transactions.
Service agent
You should assume
other services are not
part of ACID transaction
(unless using MSMQ).
Rollbacks handled with
compensations.
Transaction Management
Using ACID Transactions
Only use a transaction when needed.
Not every update requires the cost of a
transaction.
Reads for user interfaces don’t need
transactions.
Data exchange outside of transaction
boundary is disconnected and potentially
stale.
Need to consider the type of concurrency.
Optimistic—disconnected environment
Pessimistic—connected environment
Atomic Transaction Management
Selecting the Atomic Transaction Model
Do not implement
transactions
Push transaction
to the database
Using stored Yes
procedures? No
No
Need
transaction? Yes
Operating No
with multiple
resource managers?
Yes
No
Need two Yes
stage commit?
Use ADO.NET
transactions
Use Enterprise
Services
Optimistic Locking
Dealing with Disconnected Concurrent Data Access
Consistency vs. concurrency vs. scalability
Efficient for disconnected environments
Assume data is potentially stale
Time (time-out or time stamps)
Comparing the data or certain parts
Example: submitting an order with old catalog prices
Need to resolve conflicts
Comparing which fields changed
Automatic or manual
Example: updating customer records
Summary Recommendations:
Transaction Management
Guidance on transactions available
“How to Code ADO.NET Manual
Transactions” in the .NET Data Access
Architecture Guide
“Designing Data Tier Components and
Passing Data Through Tiers”
http://msdn.microsoft.com/practices/
Caching
Roles of Caches in Service-Oriented
Architectures
Why cache?
Performance? Scalability? Availability?
Where to cache?
ASP.NET cache—page and fragment
SQL Server—persistent caches
MMF—sharing across processes in memory
Memory-static hash tables—within an application
domain
What to cache?
Non-transactional, reference data
Infrequently changing data
Applicable to as many users as possible
Caching
Presentation Tier and Service Interfaces
ASP.NET
Output page caching
Very fast, but no user customization.
Think of as formatted business data.
Page fragment caching
Allows overall customization of page.
Not as fast, but excellent for heavily
formatted data.
Windows Forms
Reduce round trips to Web services
Caching
Data Access Components
Three main scenarios
Application domain-wide cache
Cache in static variables
(such as ASP.NET)
Machine-wide cache
Cache in memory-mapped files
Interop issues
Data center-wide cache
SQL Server
Session State Management
Facility to handle transient state
between Web request on the server
ASP.NET Allows three locations
In-memory: single box
Session service: in-memory for Web farm
SQL Server: persistent for Web farm
Session Agenda
Services
Security
State and transaction management
Availability and scalability
High Availability
The Problem Domain
Design Considerations
No single point of failure
Service-oriented architecture
and message-based
communications
Load balancing
Clustering
Isolate failures
Time to recover
System that recovers
automatically may appear to
have greater availability
Queuing and caching
Improves availability
Improves perceived performance
Improves perceived availability
Required to resolve database
scaling
Data partitioning
High Availability
Principle: plan for failures
Application
State management
Resiliency—fast recovery
Infrastructure
No single point of failure
Both servers and network elements
Microsoft Systems Architecture
Data
Replication, log shipping, partitioning
High Availability
Network Load Balancing
For cloned, “stateless” services
such as ASP.NET, Enterprise Services (COM+)
Scale out the application server farm
Built-in support for NLB in .NET Server
Manages sharing the load.
Supports cluster, node, and port management.
May be layered with presentation and business
services balanced separately.
Management simplified with
Application Center
High Availability
Clustering
For services that require storage
Automatic failover management
Provides for resilience and reliability
Scalability: up and partitioning
Not just for database servers
Anything that maintains persistent state
Exchange servers
BizTalk servers
MSMQ
High Availability
Software Solutions
Availability and scalability are achieved by
composing infrastructure and application.
Message Queuing and
asynchronous operations
Move bulk of work away from client.
Back-end elements may be offline without
impacting client’s view of application.
Data partitioning
Not recommended, but available when a
database needs greater scalability.
Summary Recommendations:
High Availability
Load balancing and clustering both impact
reliability and availability.
Increase scalability by designing software
that optimizes resource use.
Highly available systems are the result of People –
Process – Technology.
The people who build an application, the
technology used to implement it, and the process
of creating a highly available system.
Microsoft Systems Architecture
Session Summary
Microsoft Windows Server 2003 + Microsoft
Visual® Studio® .NET 2003 + practices = a
complete application platform
Security, management, and communications
Performance, availability, and scalability
Robust development platform for many app
scenarios
Resources for architects:
http://msdn.microsoft.com/architecture/
Guidance and best practices:
http://msdn.microsoft.com/practices/
Important Web Resources
Microsoft patterns & practices
http://msdn.microsoft.com/practices/
MSDN .NET Architecture Center
http://msdn.microsoft.com/architecture/
Microsoft Visual Studio .NET 2003
http://msdn.microsoft.com/vstudio/
Microsoft Windows Server 2003
http://www.microsoft.com/windows/
© 2003 Microsoft Corporation. All rights reserved.
Microsoft, Visual Studio, the Visual Studio logo, Windows, the Windows logo, BizTalk, Active Directory, SQL Server, and MSDN are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.