Web Services Security Requirements Stephen T. Whitlock Security
20 Slides120.50 KB
Web Services Security Requirements Stephen T. Whitlock Security Architect Boeing
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
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
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
More Infrastructure Protection Requirements Resource protection Server and network isolation Server resource control Network bandwidth control Centralized Policy administration Provisioning Access control Auditing Monitoring
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
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
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
WSSO – Desired Service Request Requestin Requestin ggweb web service service 1. Client request 2. Application request 3. Service response 22 Service Service11 33
WSSO – Needed Security Request Requestin Requestin ggweb web service service Application authentication User authentication Enterprise protection Confidentiality Message integrity Audit trail Signature Service protection Access control 22 2 Service 11 2 Service
WSSO – Existing Security Request 1. Client logon 2. Client request 3. Application 8. Application certificate request SSL/TLS Perimeter to protect applicatio n Authenticati Authenticati on onService Service Requestin Requestin ggweb web service service 5. Check for revocation 7. Credential cache 9. Service response Validatio Validatio n Service n Service 4. Authentication Request 22 2 Service 11 2 Service Directory 6. Directory attribute check
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 2 seconds Supports 1500 concurrent users, average of 1000 TPM, peak of 2000 TPM Currently undergoing an expansion and conversion to web services
EDA Architecture User L o a d B a l Internet User Intranet For SOAP objects HTTP Server Web Server EJB Container For web pages Other systems and data New Datastore Datastore Manager SOAP Messages Legacy Datastore
EDA Needed Security Enterprise protection Confidentiality User User authentication L o a d HTTP Server Web Server EJB Container B a l Internet User authentication User Intranet Confidentiality Message integrity Audit trail Signature Service resource protection Access control New Datastore Other systems and data Datastore Manager Legacy Datastore Application authentication
EDA Existing Security User Internet User Intranet F i r e w a l l R e v P r o x y L o a d B a l HTTP Server Web Server EJB Container Directory based Authentication And access Control Service New Datastore Other systems and data Datastore Manager Legacy Datastore
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
CPI Architecture Object Database Common Look And Feel Services Navigation Services Descriptions Access Rules Descr.Descr. Obj 1 Obj 2 Access Rules Database Descr. Obj n Parts Descriptions Inventory Access Rules Inv. Inv. Obj 1 Obj 2 Inv. Obj n Parts Inventory Status
CPI Needed Security Enterprise protection User authentication User Authorization Object Database Common Look And Feel Services Navigation Services Descriptions Access Rules Descr.Descr. Obj 1 Obj 2 Confidentiality Message integrity Audit trail Signature Application access control Access Rules Database Descr. Obj n Parts Descriptions Inventory Access Rules Inv. Inv. Obj 1 Obj 2 Inv. Obj n Parts Inventory Status
Directory and Certificate based Authentication And access Control Service CPI Existing Security Perimeter Services Object Database Common Look And Feel Services Navigation Services Descriptions Access Rules Descr.Descr. Obj 1 Obj 2 Access Rules Database Descr. Obj n Parts Descriptions Inventory Access Rules Inv. Inv. Obj 1 Obj 2 Inv. Obj n Parts Inventory Status
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