Navigating Web Services Standards
NIST Special Publication 800-95
Herndon, VA
October 12, 2006
NIST SP 800-95
 Draft released August 30, 2006
– http://csrc.nist.gov/publications/drafts.html#sp800-95
 Public comment period ends October 30, 2006
– E-mail 800-95comments@nist.gov
– “Comments SP800-95” in the subject line
 No NIST guidance for Web services prior to 800-95
1
Table Of Contents
 NIST SP 800-95 Structure
 Web Service Security Functions and Technologies
 Web Portals
 Secure Web Service-Enabling of Legacy Applications
 Secure Implementation
 Secure Development Scenarios
2
Table Of Contents
 NIST SP 800-95 Structure
 Web Service Security Functions and Technologies
 Web Portals
 Secure Web Service-Enabling of Legacy Applications
 Secure Implementation
 Secure Development Scenarios
3
NIST SP 800-95 Structure
 Introduction
– Introduction to Web services
– Overview of security challenges facing Web services
– Overview of how those challenges can be met
 Web Service Security Standards and Technologies
– Authentication
– Authorization and Access Management
– Confidentiality and Integrity
– Accountability
– Availability
– Securing Discovery
4
NIST SP 800-95 Structure, cont’d…
 Web Portals
– Portals acting on behalf of users
– User authorization and access to Web services
– Portal interaction with discovery services
 Web service-enabling of legacy applications
– Authentication
– Authorization and Access Control
– Public Key-Enabling
– Accountability
– Database Security Challenges
– Integrity
5
NIST SP 800-95 Structure, cont’d…
 Secure Implementation Tools and Technologies
– General discussion of Web services developer toolkits
– How XML parsers affect security
– Languages for secure Web services development: Java, .NET, C, and C++
– Security Testing
 Secure Development Scenarios
– Implementing Web services from scratch
– Implementing heterogeneous Web services
– Enabling a legacy system using Net-Centric Enterprise Services
– Using XML Gateways to “security enable” existing Web services
6
Table Of Contents
 NIST SP 800-95 Structure
 Web Service Security Functions and Technologies
 Web Portals
 Secure Web Service-Enabling of Legacy Applications
 Secure Implementation
 Secure Development Scenarios
7
Web Services Standards Related To Security
Dimension
Requirement
Confidentiality and Integrity
Messaging
Authentication
Specifications
WS-Security (XML Enc.)
SSL/TLS (HTTPS)
WS-Security (SAML, X.509)
SSL/TLS (X.509)
XACML
Authorization
RBAC, ABAC
Resource
Privacy
Accountability
Registries
Negotiation
XrML
Semantic Discovery
Business Contracts
EPAL
XACML
Auditing tools, NIST SP 800-92
UDDI
ebXML
SWSA
OWL-S
ebXML
These dimensions are based on those defined in the paper Securing Service-Based Interactions: Issues and Directions by Hamid Nezhad, et al
8
Web Services Standards Related To Security
WS-Trust
Establishment
XKMS
X.509
SAML
Trust
Proxying
WS-Trust
WS-Federation
Federation
Liberty IDFF
Shibboleth
Policy
WS-Policy
Security Policy
WS-SecurityPolicy
Security Properties
WS-ReliableMessaging
Availability
WS-Reliability
These dimensions are based on those defined in the paper Securing Service-Based Interactions: Issues and Directions by Hamid Nezhad, et al
9
Identification, Authentication and Authorization
 SSL-certificates
– SSL between two Web services can provide identification and authentication of the
host machines
– This does not authenticate individual Web services
– This is only a point-to-point solution
 WS-Security
– Message-level authentication
– Supports a variety of authentication Tokens: X.509, SAML, username/password
10
Distributed Authorization
 SAML
– SAML Assertions allow a trusted third party to digitally sign a user’s attributes that can be
passed to other Web services
– SAML protocol allows Web services to send authorization queries and/or request
attributes from the identity store
– SAML 2.0 provides an XACML mapping
 XACML
– Distributed security policy based on XML
– Mechanism for querying the policy
 Using XACML and SAML together provides a distributed authorization mechanism using
interoperable XML technologies
11
Trust Federation
 Web services are limited to being able to trust the identity of the service.
– Just because a Web service’s identity can be established does not mean that the service
itself is inherently trustworthy.
 Trust federation allows organizations to share resources without merging their
authentication and authorization facilities
 WS-Federation
– Based off WS-Security and WS-Trust
– Can use any WS-Security token
 Liberty Alliance and Shibboleth
– Use SAML assertions and extend the SAML specification
12
Confidentiality, Integrity, and Availability
 Confidentiality and Integrity
– SSL provides transport-layer confidentiality and integrity
– WS-Security uses XML Encryption and XML Digital Signature to provide message-layer
confidentiality and integrity
– No support for QoP in Web services.
– OASIS refers all QoP questions to the WS-Security standard
 Availability
– WS-ReliableMessaging and WS-Reliability introduce reliable messaging to Web services
– Currently, there is no support for QoS in Web services
– Service deadlocks and recursion
13
Accountability and Securing Discovery
 Accountability remains a hard problem
– No logging standards
– Web services may be outside of organizational control
– Need for distributed logging
– SP 800-92 is a step forward
 Securing Discovery
– Discovery integrity is essential
– Discovery services open Web services to reconnaissance attacks.
– UDDI v3.0.2 supports authentication and digital signatures
– WSDL has yet to provide similar support, but out-of-band digital signatures can be used
14
Table Of Contents
 NIST SP 800-95 Structure
 Web Service Security Functions and Technologies
 Web Portals
 Secure Web Service-Enabling of Legacy Applications
 Secure Implementation
 Secure Development Scenarios
15
Web Portals
 Must satisfy security requirements of both Web applications and Web services
 Proxy Agents
– Web portals act on behalf of a user
– They may perform actions with the user’s privileges
– They may perform actions with their own privileges
 SAML
– Web portals use SAML assertions to provide information about the user
 Discovery
– Portals can offer a discovery interface
– Portals can control what services a user can or cannot discover
16
Table Of Contents
 NIST SP 800-95 Structure
 Web Service Security Functions and Technologies
 Web Portals
 Secure Web Service-Enabling of Legacy Applications
 Secure Implementation
 Secure Development Scenarios
17
Web Service-Enabling Web Applications
 Threats:
– All threats facing Web services now face the legacy application
– Flaws in the application may be exploited remotely
 Legacy Web Applications
– Web applications can securely authenticate with a Web service front-end using mutual
SSL/TLS authentication
– Some Web applications can be modified to support SAML in addition to SSL/TLS
– SSL/TLS provides confidentiality and integrity protection as well
 Authorization and Access Control
– Legacy apps may rely on their own authorization and access control scheme and not an
SSO server
– SSL/TLS should be used to secure any remote directory access
– The Web service front-end may need to translate SAML assertions into legacy
authentication requests
18
Web Service-Enabling Non-Web Applications
 Non Web applications that are Web service-enabled are usually databases or directory
services
 Many of the same techniques can be used
– SSL for communicating between the Web service front-end and the legacy application
– Modification for SAML support if possible
– Mapping for legacy authentication and authorization system if necessary
19
Accountability and Integrity
 Auditing is necessary to provide accountability in the SOA
 There are no auditing standards for Web services and there are no guarantees the legacy
application has auditing support
– If the application supports auditing, it should be stored security
– If the application does not support auditing, it should be modified or the Web service frontend should perform additional auditing
– NIST SP 800-92 provides some guidelines for managing auditing
 Security must not stop at the Web service interface
– End-to-end user authentication from requester to the legacy application
– End-to-end encrypted channel using IPSec or SSL tunneling between the Web service
interface and legacy application if necessary
– PKE’d security end-to-end and integrate it with legacy security systems
20
Table Of Contents
 NIST SP 800-95 Structure
 Web Service Security Functions and Technologies
 Web Portals
 Secure Web Service-Enabling of Legacy Applications
 Secure Implementation
 Secure Development Scenarios
21
Developer Toolkit Requirements
 Web service language requirements?
– Java, .NET, C, or C++
– Toolkits available for each language
 Interoperability support?
– WS-Interoperability Organization Basic Profile
– (Upcoming) Basic Security Profile
 Does it generate stubs?
– Code that performs the necessary SOAP message parsing and generation
– Allows developers to focus on functional requirements
 How difficult is it to add WS-Security and SAML support?
22
XML Parsers
 XML Parsers are the first component to process input to Web services
– They must be robust
– Large or specially formed XML documents can lead to DoS
– Specially formed XML documents may be able to retrieve information about the system
through parsing errors
– Specially formed XML documents may be able to use external references to custom XML
schemas to bypass validation requirements
23
Programming Languages: C, C++, Java, .NET
 C and C++
– Less overhead, which is useful for embedded systems: J2EE and .NET frameworks take up
hundreds of megabytes of hard disk space
– Can directly interface with legacy applications developed in C or C++
– Support for WS-Security and SAML
– Susceptibility to programming errors may require addition protections like XML Gateways or
OS level restrictions
 Java and .NET
– Widely considered to be more secure languages
– Two of the most popular languages for developing Web services
– Provide robust sandboxes (JVM and .NET Code Access Security)
– Provide code obfuscation techniques
– Large number of third-party libraries available for Java and .NET Web services
24
Security Testing
 Developers are not perfect. Many defects are not found until testing is performed.
 Conformance testing of security protocol implementation
– Third-party testing to prove standards compliance
 Functional testing of Web service security mechanisms
– Ensure that Web service security mechanisms function as required
 Security-focused unit testing
– Performing security testing on individual components of the Web service, such as classes
 Vulnerability assessments
– Attempting to attack the Web service using known attack types
 Web service code security reviews and testing
– Check the source code for vulnerabilities or security errors
– Perform testing with unexpected or random input to find susceptibility to unknown attacks
25
Table Of Contents
 NIST SP 800-95 Structure
 Web Service Security Functions and Technologies
 Web Portals
 Secure Web Service-Enabling of Legacy Applications
 Secure Implementation
 Secure Development Scenarios
26
Development Scenarios
 Provide rough guides for how to use Web service standards appropriately
 Six goals:
– Confidentiality – Provided by WS-Security’s encryption functionality
– Integrity – Provided by WS-Security’s signature functionality
– Availability – Remains difficult
– Privilege – Provided partially by SAML and XACML
– Non-repudiation – Provided partially by WS-Security’s signature functionality
– Accountability – Remains difficult
27
Developing a Web service from scratch
UDDI Registry
XKMS
Producer
Web Service
Identity Provider
Consumer
Web Service
28
1
Provider registers
with UDDI
2
Requester discovers
Provider using UDDI
UDDI Registry
XKMS
Identity Provider
3
Requester receives
SAML Assertion prior
to requesting
5
Provider verifies requester ID
and message
Provider
Web Service
Provider sends SOAP
response using WS-Security
6
4
Requester sends SOAP
request using WS-Security
7
Requester
Web Service
Provider verifies provider ID
and message
29
Heterogeneous Web services
WSDL
PKI
.NET
Web Service
Identity Provider
Java
Web Service
30
WSDL
2
2
1
WSDL is used to Implement
the .NET service
WSDL is created
prior to implementation
WS-I
Basic Profile
WS-I
Basic Profile
3
3
PKI
Identity Provider
The .NET service is
Implemented on a WS-I
Basic Profile 1.0-compliant
framework
Requester receives
SAML Assertion prior
to requesting
4
5
WSDL is used to Implement
the Java service
.NET
Web Service Provider verifies requester ID
and message
The Java service is
Implemented on a WS-I
Basic Profile 1.0-compliant
framework
Web services exchange SOAP
messages using WS-Security
5
Java
Web Service
Provider verifies provider ID
and message
31
Legacy system
Discovery Service
PKI
Legacy Application
Provider
Web Service
Identity, Authentication,
and Authorization Services
Requester
Web Service
32
2
1
Provider registers
with discovery service
Requester discovers
provider through
discovery service
Discovery Service
PKI
Identity, Authentication,
and Authorization Services
6
3
Provider converts SOAP
messages to legacy requests
and responses
5
Requester registers
with core services
Provider offloads verification
to core services
4
Legacy Application
7
Provider
Web Service
Web services exchange SOAP
messages using WS-Security
Requester
Web Service
Legacy app verifies provider id
Using legacy authentication
33
XML Gateways
PKI
Provider
Web Service
XML Gateway
Identity Provider
XML Gateway
Requester
Web Service
34
Identity Provider
PKI
2
XML Gateway receives
a SAML assertion
5
1
XML Gateway verifies
SAML assertion and
SOAP message and forwards
Insecure version to provider
Requester sends SOAP
message to the XML
Gateway with a specific URI
and will receive a response
4
Provider
6
Web Service
Provider receives the
SOAP message and
sends a response
XML Gateway
SOAP message sent
to the requester URI
XML Gateway
3
Requester
Web Service
XML Gateway signs, encrypts, and adds
SAML assertion to the SOAP message
35
Questions?
36