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

Back to top button