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. 3 3 2 2 WSSO – Desired Service Requesting web service Request Service 1 1. Client request 2. Application request3. Service response

10. 2 2 2 2 WSSO – Needed Security Requesting web service Service 1 Request Service protection Access control User authentication Enterprise protection Application authentication Confidentiality Message integrity Audit trail Signature

11. 2 2 2 2 WSSO – Existing Security Requesting web service Service 1 Authentication Service Directory Request Validation Service 1. Client logon 3. Application certificate 9. Service response 2. Client request 4. Authentication Request 5. Check for revocation 6. Directory attribute check 8. Application request 7. Credential cache SSL/TLS Perimeter to protect application

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 < 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 Intranet User HTTP Server Web Server EJB Container New Datastore Legacy Datastore Other systems and data Datastore Manager LoadBalLoadBal SOAP Messages For web pages For SOAP objects

14. EDA Needed Security Internet Intranet User HTTP Server Web Server EJB Container New Datastore Legacy Datastore Other systems and data Datastore Manager LoadBalLoadBal Enterprise protection Confidentiality User authentication Service resource protection Access control Application authentication Confidentiality Message integrity Audit trail Signature User authentication

15. EDA Existing Security Internet Intranet User HTTP Server Web Server EJB Container Directory based Authentication And access Control Service New Datastore Legacy Datastore Other systems and data Datastore Manager RevProxyRevProxy FirewallFirewall LoadBalLoadBal

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 Navigation Services Object Database Access Rules Database Parts Descriptions Descriptions Access Rules Descr. Obj 1 Descr. Obj 2 Descr. Obj n … Parts Inventory Status Inventory Access Rules Inv. Obj 1 Inv. Obj 2 Inv. Obj n … Common Look And Feel Services …

18. CPI Needed Security Navigation Services Object Database Access Rules Database Parts Descriptions Descriptions Access Rules Descr. Obj 1 Descr. Obj 2 Descr. Obj n … Parts Inventory Status Inventory Access Rules Inv. Obj 1 Inv. Obj 2 Inv. Obj n … Common Look And Feel Services … Enterprise protection User authentication User Authorization Confidentiality Message integrity Audit trail Signature Application access control

19. CPI Existing Security Navigation Services Object Database Access Rules Database Parts Descriptions Descriptions Access Rules Descr. Obj 1 Descr. Obj 2 Descr. Obj n … Parts Inventory Status Inventory Access Rules Inv. Obj 1 Inv. Obj 2 Inv. Obj n … Common Look And Feel Services … Directory and Certificate based Authentication And access Control Service Perimeter 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