Web Services Security Requirements

1
Web Services Security Requirements

• Stephen T. Whitlock
• Security Architect
• Boeing

2
Outline

• Disclaimer
• Requirements are from a user perspective to cover
  the use of web services in our environment
• Some of these requirements are met by existing
  technologies
• Requirements
• WS data/transaction/orchestration
• Infrastructure
• General
• Examples

3
WS Transaction/Orchestration Protection
Requirements

• Data protection
• Integrity
• Confidentiality
• Privacy support
• Attack resistant to
• Replay attacks
• Person in the middle attacks
• Orchestration hijacking
• Evidence to support non-repudiation
• Signature
• Timestamp
• Audit trail

4
Infrastructure Protection Requirements

• Transport
• Integrity
• Confidentiality
• Authentication
• Multiple mechanisms certificates, shared
  secrets, Kerberos/AD
• Application authentication
• User authentication
• Access control
• Multiple mechanisms RBAC, directory based
• Credential propagation
• Credential caching
• Transaction level granularity resource or
  application access authorized separately from
  individual transaction authorization

5
More Infrastructure Protection Requirements

• Resource protection
• Server and network isolation
• Server resource control
• Network bandwidth control
• Centralized
• Policy administration
• Provisioning
• Access control
• Auditing
• Monitoring

6
General Requirements

• User transparent (AMAP)
• Standards based
• Vendor neutral
• Interoperable no proprietary value-added
  extensions
• IPR Free
• Compatible with existing security technology
• VPNs IPSec, TLS
• PKI
• LDAP
• Performance
• Support for real time applications
• Reliable
• Redundancy
• Extensible
• Development environment that enables and promotes
  the creation of secure web services

7
Future Requirements

• Secure context passing between different web
  services
• Pass a security context through an integration
  broker including support for
• End to end access
• The ability to switch between environments such
  as J2EE and .NET

8
Example 1 Web Single Sign On (WSSO) based end to
end security

• WSSO accepts user credentials
• Account, password, X.509 certificate
• Front end to multiple applications
• Using the same approach to provide web service to
  web service application security

9
WSSO Desired Service
Requesting web service
Request
1. Client request
2. Application request
3. Service response
2
Service 1
3
10
WSSO Needed Security
Requesting web service
Application authentication
Request
User authentication Enterprise protection
Confidentiality Message integrity Audit
trail Signature
2
2
Service protection Access control
11
WSSO Existing Security
Authentication Service
Requesting web service
Request
5. Check for revocation
1. Client logon
2. Client request
7. Credential cache
Validation Service
3. Application certificate
8. Application request
9. Service response
SSL/TLS
4. Authentication Request
2
2
Perimeter to protect application
Directory
6. Directory attribute check
12
Example 2 Engineering Drawing Application (EDA)

• Supports engineering drawings and parts lists
• Total database size 1.5TB, About 15M documents,
  Average document size 100KB
• Query to retrieval time lt 2 seconds
• Supports 1500 concurrent users, average of 1000
  TPM, peak of 2000 TPM
• Currently undergoing an expansion and conversion
  to web services

13
EDA Architecture
Internet
L o a d B a l
For SOAP objects
For web pages
User
Other systems and data
New Datastore
SOAP Messages
User
Datastore Manager
Legacy Datastore
Intranet
14
EDA Needed Security
Confidentiality Message integrity Audit
trail Signature
Enterprise protection Confidentiality
Internet
L o a d B a l
User
User authentication
New Datastore
Other systems and data
User authentication
User
Datastore Manager
Legacy Datastore
Service resource protection Access control
Intranet
Application authentication
15
EDA Existing Security
Internet
R e v P r o x y
F i r e w a l l
L o a d B a l
Directory based Authentication And access Control
Service
User
New Datastore
Other systems and data
User
Datastore Manager
Legacy Datastore
Intranet
16
Centralized Parts Inventory (CPI)

• Descriptions of parts
• Current parts stock level information
• Originally a collection of disparate web sites
  linked to different databases
• In the process of being converted to a
  centralized service that provides a common look
  and feel and navigation services

17
CPI Architecture
Common Look And Feel Services

18
CPI Needed Security
Enterprise protection User authentication User
Authorization
Confidentiality Message integrity Audit
trail Signature Application access control
Common Look And Feel Services

19
CPI Existing Security
Directory and Certificate based Authentication An
d access Control Service
Perimeter Services
Common Look And Feel Services

20
Conclusions

• We need data protection for web services messages
• SSL/TLS is insufficient because it only provides
  integrity at the packet level, not at the XML
  message level
• We need interoperable, multivendor solutions
• Security solutions need to integrate with
  existing security technologies
• Security solutions must work between enterprises
  as well as within them