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. Service 1 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. Service 1 WSSO – Existing Security Authentication Service Requesting web service Request 5. Check for revocation 1. Client logon 2. Client request 7. Credential cache 3. Application certificate Validation Service 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 < 2 seconds • Supports 1500 concurrent users, average of 1000 TPM, peak of 2000 TPM • Currently undergoing an expansion and conversion to web services

13. HTTP Server Web Server EJB Container 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. HTTP Server Web Server EJB Container 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. HTTP Server Web Server EJB Container EDA Existing Security Internet F i r e w a l l R e v P r o x y 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. Navigation Services Object Database Access Rules Database Parts Descriptions Descriptions Access Rules Parts Inventory Status Inventory Access Rules … Descr. Obj 1 Descr. Obj 2 Descr. Obj n … Inv. Obj 1 Inv. Obj 2 Inv. Obj n CPI Architecture Common Look And Feel Services …

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

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