Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
- From Vision and Direction to Deployment
Implementing the Directions and Priorities for Government ICT and Better Public Services
Government Enterprise Architecture
for New Zealand (GEA-NZ) - Standards
Secure Web Services Standard Appendices
Department of Internal Affairs
April 2013
Unclassified
Department of Internal Affairs
CROWN COPYRIGHT ©
This work is licensed under the Creative Commons Attribution 3.0 New Zealand licence. In essence, you are free to copy,
distribute and adapt the work, as long as you attribute the work to the Crown and abide by the other licence terms.
To view a copy of this licence, visit http://creativecommons.org/licenses/by/3.0/nz/.
Please note that no departmental or governmental emblem, logo or Coat of Arms may be used in any way which infringes any
provision of the Flags, Emblems, and Names Protection Act 1981. Attribution to the Crown should be in written form and not by
reproduction of any such emblem, logo or Coat of Arms.
This document contains some new materials derived from the Microsoft ―Web Service Security Guide‖. With respect to ―Web
Service Security Guide‖ (Available from http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=6485),
Microsoft Corporation grants to the Department of Internal Affairs, New Zealand Government, without payment of any royalty or
fee, a perpetual, irrevocable, worldwide, nonexclusive copyright license to prepare derivative works thereof of the ―Web Service
Security Guide‖ and to distribute and publicly display those derivative works without attribution or any duty to account. For the
avoidance of doubt: Microsoft, as it does not control the contents of the derivative works, requests that no attribution of source be
included in any derivative work, and therefore does not impose any conditions or restrictions on the Department of Internal Affairs,
New Zealand Government downstream copyright license terms.
Department of Internal Affairs
Document control
Document information
Project
ID/Name New Zealand Secure Web Services Standard
Author New Zealand Secure Web Services Standard Working Group
Title NZ Government Standards Working Group
File name Secure Web Services Standard Appendices January 2013 Final Draft.doc
DMS
reference TBC
Revision history
Version Date Author Description of changes
1.0FD 16/01/2013 New Zealand Secure
Web Services Working
Group
Final Draft for Government Enterprise
Architecture Group (GEAG) review and
endorsement
1.0 Final
including
GEAG
changes
15/04/2013 New Zealand Secure
Web Services Working
Group
Includes Government Enterprise
Architecture Group (GEAG) required
changes.
1.0 18/04/2013 New Zealand Secure
Web Services Working
Group
Approved Final
Distribution list
Name Role Group
Stuart Wakefield Chair Government Enterprise Architecture Group
Brian More Official Government Enterprise Architecture Group
Mark Baddeley Member Government Enterprise Architecture Group
Mark Carroll Member Government Enterprise Architecture Group
James Collier Member Government Enterprise Architecture Group
Dan Cooper Member Government Enterprise Architecture Group
Jon Frere Member Government Enterprise Architecture Group
Tina Groark Member Government Enterprise Architecture Group
Paul Henzell Member Government Enterprise Architecture Group
Rosemary McGrath Member Government Enterprise Architecture Group
Department of Internal Affairs
Department of Internal Affairs
Table of Contents
Appendix A – Further detail on Web service security characteristics 7
A.1 Service integrity 7
A.2 Confidentiality 7
A.3 Authentication 7
a) Consistent authentication 8
b) Identity authentication 8
A.4 Non-repudiation 8
a) Content non-repudiation 8
b) Event Non-repudiation 9
Appendix B - Web service security specifications, standards and profiles 10
B.1 Specifications 11
B.2 Standards profiles 13
B.3 Transport layer security 14
B.4 Identity 15
B.5 Profile descriptions 16
B.6 OASIS Web services security specifications 20
Appendix C - Architectural patterns 22
C.1 Data confidentiality 25
C.2 Data integrity and origin authentication 30
C.3 Message Screening 36
C.4 Direct authentication pattern 40
C.5 Brokered authentication: Security Token Service 46
C.6 Brokered authentication: X.509 PKI 53
C.7 Origin non-repudiation 60
C.8 Delivery non-repudiation 63
C.9 Secure Context Centralisation 68
Department of Internal Affairs
Figures
Figure 1 – WS-I Basic Security Profile Footprint 18
Figure 2 - Data confidentiality using symmetric cryptography 26
Figure 3- Data confidentiality using asymmetric cryptography 27
Figure 4 - Data integrity using symmetric signatures 32
Figure 5- Data integrity using asymmetric signatures 33
Figure 6 – Message screening 37
Figure 10 - Brokered authentication X.509 55
Figure 11- Origin Non-repudiation 61
Figure 12 - Delivery non-repudiation of service request 65
Figure 13 - Delivery non-repudiation of service response 66
Figure 14 - Secure conversation using Security Token Service 70
Figure 15 - Secure conversation using security context propagation 71
Figure 16 - Secure conversation created through negotiation 72
Department of Internal Affairs 7
Appendix A – Further detail on Web service security
characteristics
A.1 Service integrity
A Web service has integrity when it can be assumed that, inadvertent or deliberate
modification of the information or process can be detected when it occurs. Web service
integrity is a prerequisite of all the Web service security techniques discussed in this
document. Service integrity is established between the service consumer and service
provider.
A.2 Confidentiality
Websters Dictionary, “Confidentiality”
“…Ensuring that information stored on computers is not accessed by
unauthorised individuals…”
Confidentiality in the Web service security context means keeping the Web service
execution and data content private/secret. Confidentiality is established between the
service consumer and service provider.
A.3 Authentication
Websters legal dictionary, “Authentication”
“…to prove or serve to prove that (something) is genuine; especially : to prove that (an
item of evidence) is genuine for the purpose of establishing admissibility…”.
In the context of Web service security ―authentication‖ is the process of verifying the
identity and authority of the parties involved in a Web service including in the identity of
the provider.
A Web service is a machine interaction. However, the interaction is usually at the
behest of an individual or organisation using electronic assertions of their identities and
authority for use of the service.
Web service consumer and Web service provider machines may represent an identity.
Both machines may represent an organisation by using electronic assertions of
organisational identity. Where a Web service is being consumed at the behest of a
human user the service consumer machine may assert their personal identity.
Two types of authentication may be applied, ―consistent authentication‖ and ―identity
authentication‖. The service consumer and service provider authenticate separately.
Department of Internal Affairs 8
a) Consistent authentication
Consistent authentication is the establishment of an anonymous but repeatable
identity. The identity is anonymous because it does not have to be based on a
verifiable real personal identity or organisational identity. The primary purpose of this
type of authentication is to support efficient service delivery and operation and not to
identify specific service consumers. Consistent authentication provides a limited
identity assertion that can only be used to establish a repeat service consumer where a
true identity is not required.
b) Identity authentication
Identity authentication is the verification of a real identity. The identity is deemed to be
real because it has a verifiable link back to an actual person or organisation. Identity
authentication provides identity assertions representing the service consumer and
service provider. Identity authentication may provide a personal or organisational
identity assertion. The quality of the available identity assertion will determine its
applicability to delivering secure services. Identity authentication is required for
confidentiality and non-repudiation.
Both consistent authentication and identity authentication can be implemented using a
brokered identity architecture (using a third party identity service).
A.4 Non-repudiation
BusinessDictionary.com dictionary “Electronic Commerce: Non-repudiation”
“…Intent to accept responsibility of submitting or receiving an electronic message and
be bound by its substance. Non repudiation protects a sender against the false
assertion of the receiver that the message has not been received, and a receiver
against the false assertion of the sender that the message has been sent. An essential
element of secure electronic commerce, non repudiation is generally established by
the protocol (such a public key infrastructure or EDIFACT) used in data transfer, and
includes legal and security criteria of authentication and report integrity….”.
Web services non-repudiation may be applied to content (artefacts, data exchanges) or
processing events. Web service Non-repudiation terms are agreed between the
service consumer and service provider but may be implemented by either party. Non-
repudiation is more than just an electronic service design for secure Web services. It
involves record keeping and legal contracts and the means needed for resolving
delayed disputes.
a) Content non-repudiation
Content non-repudiation specifically addresses sender content non-repudiation
requirements, supporting verification of ―what has been sent‖. In Web services terms
Department of Internal Affairs 9
the sender may be either the service consumer or a service provider. Depending upon
the service operating scenario the sender may be requesting or responding. Content
non-repudiation is the establishment of content non-repudiation materials that are
delivered as part of a Web service content package. The scope of non-repudiation
materials will be defined and agreed by the parties entering into a non-repudiation
service agreement, however content non-repudiation as discussed in this document
focuses on the sender Web service content and not the Web service processing
events that are involved in the service.
b) Event Non-repudiation
Event non-repudiation specifically addresses verification of the occurrence of particular
events. Event non-repudiation is the establishment of event non-repudiation materials
that are held by both parties. The scope of non-repudiation materials will be defined
and agreed by the parties entering into a non-repudiation service agreement, however
event non-repudiation as discussed in this document focuses on the completion state
of Web service processing events.
Department of Internal Affairs 10
Intentionally blank
Department of Internal Affairs 11
Appendix B - Web service security specifications, standards and profiles
B.1 Specifications
Role Specification NZ SWS
Data format XML 1.0 Adopts
Delivery protocol SOAP 1.1, 1.2 Adopts
Web service description WSDL 1.1 Adopts
Message level security WS-Security 1.1 Adopts
Identity messaging SAML 2.0 Adopts
Interoperable trust
messaging
WS-Trust 1.3 and 1.4 Adopts
Message level sessions WS-SecureConversation
1.3, 1.4
Adopts
Message level security
policy
WS-SecurityPolicy 1.2, 1.3 Adopts
Transport layer security TLS V 1.2 Adopts
Asymmetric cryptography X509 Digital Certificates Adopts
Encrypted content XML-Encryption Adopts
Signed content XML-Signature Adopts
XML-based registry UDDI 2.0.4 Adopts
Cryptography
Key establishment EC DH (P-256 and P-384)
or MQV1 (at least 256 bits)
NZ ISM
Message and certificate
signing
EC DSA (P-256 and P-384) NZ ISM
Hashing SHA 2 (SHA-256, SHA-384,
or SHA-512)
NZ ISM
Symmetric encryption AES (at least 128 bits)
NZ ISM
Department of Internal Affairs 12
Department of Internal Affairs 13
B.2 Standards profiles
Role
Standard/Profile Status NZ SWS
Message level
security
WS-I Basic Security
Profile 1.1
Final Adopts
SOAP with
Attachments
OASIS WSS SOAP
Message with
Attachments
Final Adopts
B2B message level
security
AS4 Profile of
ebMS 3.0 Version
1.0
Final Adopts
Web service
integrity
WS-I BasicProfile
1.2 (SOAP 1.1) or
WS-I BasicProfile
2.0 (SOAP 1.2)
Final Adopts
Web service
interoperability
WS-I Simple SOAP
Binding Profile 1.0
Final Adopts
Identity messaging WS-I SAML Token
Profile 1.1
Final Adopts
Public key
validation
OASIS X.509
Certificate Token
Profile 1.1
Final Adopts
Web service
reliability
WS-I Reliable
Secure Profile 1.0
Final Future
Consideratio
n
Department of Internal Affairs 14
B.3 Transport layer security
IETF TLS 1.2
TLS provides privacy and data integrity between two communicating applications on
top of TCP/IP.
The protocol is composed of two layers: the TLS record protocol and the TLS
handshake protocol.
The TLS record protocol provides two basic connection security properties:
The connection is private. Symmetric cryptography is used for data encryption
(e.g., Advanced Encryption Standard (AES)). The keys for this symmetric encryption
are generated uniquely for each connection and are based on a secret negotiated by
another protocol (such as the TLS handshake protocol). The record protocol can
also be used without encryption.
The connection is reliable. Message transport includes a message integrity
check using a keyed Message Authentication Code (MAC). Secure hash functions
(e.g., SHA) are used for MAC computations. The record protocol can operate without
a MAC, but is generally only used in this mode while another protocol is using the
record protocol as a transport for negotiating security parameters.
The TLS record protocol is used for encapsulation of higher-level protocols, such as
the TLS handshake protocol, that allows the server and client to authenticate each
other and to negotiate an encryption algorithm and cryptographic keys before the
application protocol transmits or receives its first byte of data.
The TLS handshake protocol provides connection security that has three basic
properties:
The peer's identity can be authenticated using asymmetric, or public key,
cryptography (e.g., EC CDH or MQV1.). This authentication can be made optional,
but is generally required for at least one of the peers.
The negotiation of a shared secret is secure: the negotiated secret is unavailable
to eavesdroppers, and for any authenticated connection the secret cannot be
obtained, even by an attacker who can place himself in the middle of the connection.
The negotiation is reliable: no attacker can modify the negotiation communication
without being detected by the parties to the communication.
Department of Internal Affairs 15
B.4 Identity
a) X.509 certificates
X.509 is a format for certified public key's, that are suitable for use in various Public
Key Infrastructure systems. X509 Certificates are useful for encrypting messages
and forming SSL network connections, such as are used in HTTPS. WS-Security
makes extensive use of X509 certificates for signing and encrypting. X.509 is a
published standard that defines a standard certificate format for public key
certificates and certification validation.
b) SAML
Security Assertion Markup Language. An XML-based format from OASIS for
exchanging security information for single sign-on. The "assertions" are statements
from a SAML authority that authenticate a user, confirm some attribute about the
individual and grant or deny authorisation. SAML provides only the message format
and may be used with protocols that perform the authentication services.
Department of Internal Affairs 16
B.5 Profile descriptions
a) WS-I Basic Profile (BP) 1.2
http://www.ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html
The WS-I Basic Profile consists of a set of constraints and guidelines for the
implementation of interoperable secure Web services. The Basic Profile 1.2 scope
includes the following specifications:
The following specifications' requirements are incorporated into the Profile by
reference, except where superseded by the Profile:
Simple Object Access Protocol (SOAP) 1.1 RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 RFC2965: HTTP State Management Mechanism WS-Addressing 1.0 - Core WS-Addressing 1.0 - SOAP Binding (except for sections 2, 3, 5.1.2, 5.2.2
and 6.1) WS-Addressing 1.0 - Metadata (except for sections 4.1.1, 4.4.2, 4.4.3 and
5.2) SOAP 1.1 Request Optional Response HTTP Binding SOAP Message Transmission Optimization Mechanism XML-Binary Optimized Packaging SOAP 1.1 Binding for MTOM 1.0 Extensible Markup Language (XML) 1.0 (Fourth Edition) Attachments Profile Version 1.0 RFC3986: Uniform Resource Identifier (URI): Generic Syntax Namespaces in XML 1.0 (Second Edition) XML Schema Part 1: Structures XML Schema Part 2: Datatypes Web Services Description Language (WSDL) 1.1 UDDI Version 2.04 API Specification, Dated 19 July 2002 UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002 UDDI Version 2 XML Schema UDDI Version 2.03 Data Structure Reference, Section 7 UDDI Version 2.03 Data Structure Reference, Section 8 RFC2818: HTTP Over TLS RFC2246: The TLS Protocol Version 1.0 The SSL Protocol Version 3.0 RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL
Profile
The WS-I Basic Profile 1.2 supersedes Basic Profile 1.1 and Basic Profile 1.0. In
Basic Profile 1.1, the serialisation of envelopes over HTTP is split off into a separate
profile, the Simple SOAP Binding Profile (SSBP) 1.0.
For the purposes of this standard, implementation of UDDI is not recommended. A
consensus is emerging among practitioners that this Standard has not been widely
implemented and does not meet needs in this area. Unfortunately, no consensus
exists on the replacement. For updates to this position, check the Web location of
this Standard (see references section).
Department of Internal Affairs 17
b) WS-I BasicProfile (BP) 2.0
http://www.ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html
The following specifications' requirements are incorporated into the Profile by
reference, except where superseded by the Profile:
SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) SOAP Version 1.2 Part 2: Adjuncts (Second Edition) RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 RFC2965: HTTP State Management Mechanism WS-Addressing 1.0 - Core WS-Addressing 1.0 - SOAP Binding (except for sections 4, 5.1.1, 5.2.1
and 6.2) WS-Addressing 1.0 - Metadata (except for sections 4.1.1, 4.4.2, 4.4.3
and 5.2) SOAP Message Transmission Optimization Mechanism XML-Binary Optimized Packaging XML Media Types Extensible Markup Language (XML) 1.0 (Fourth Edition) Attachments Profile Version 1.0 RFC3986: Uniform Resource Identifier (URI): Generic Syntax Namespaces in XML 1.0 (Second Edition) XML Schema Part 1: Structures XML Schema Part 2: Datatypes Web Services Description Language (WSDL) 1.1 WSDL 1.1 Binding Extension for SOAP 1.2 UDDI Version 2.04 API Specification, Dated 19 July 2002 UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002 UDDI Version 2 XML Schema UDDI Version 2.03 Data Structure Reference, Section 7 UDDI Version 2.03 Data Structure Reference, Section 8 RFC2818: HTTP Over TLS RFC2246: The TLS Protocol Version 1.0 The SSL Protocol Version 3.0 RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL
Profile
c) WS-I Simple SOAP Binding Profile (SSBP) 1.0
http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html
The SSBP 1.0 consists of a series of constraints and guidelines on how to serialise
SOAP messages over HTTP. It includes the following specifications:
o Simple Object Access Protocol (SOAP) 1.1
o Extensible Markup Language (XML) 1.0 (Second Edition)
o RFC2616: Hypertext Transfer Protocol — HTTP/1.1
o Web Services Description Language (WSDL) 1.1, Section 3
o Namespaces in XML 1.0
Department of Internal Affairs 18
d) WS-I Basic Security Profile (BSP) 1.1
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html
The WS-I Basic Security Profile provides both simplification and implementation
guidance on the combined use of the WS-Security standards set, reducing the
complexity and providing interoperability of specific security capabilities.
The WS-I Basic Security Profile takes interoperability as a prime consideration and
profiles and interprets the OASIS WS-Security standards set accordingly.
It builds on the WS-Security specifications, WS-I Basic Profile 1.1 (BP 1.1), and the
Simple SOAP Binding Profile 1.0 (SSBP 1.0.)
The Basic Security Profile is consistent with BP 1.1 and SSBP 1.0, but provides for
additional functionality by profiles which show how to add security features to the
Basic Profile. It builds on the following underlying specifications:
o HTTP Over TLS
o Web services security: SOAP message security
o Web services security: username token profile
o Web services security: X.509 token profile
o XML-Signature syntax and processing
o Web services security: SOAP message security section 9
o XML Encryption syntax and processing
WS-I Basic Security Profile V1.1 provides guidance and advice on narrowing the
options for security implementation of Web services based upon WS-Security. This is
particularly useful with WS-Security. WS-I Basic Security Profile 1.1 should be used
with all WS-Security implementations.
Note. Although WS-I Basic Security Profile does comment on some characteristics of
TLS implementations TLS can be difficult to configure in line with the profile
recommendations.
Department of Internal Affairs 19
The diagram below shows the WS-Security standards set, the footprint of the WS-I
Basic Security Profile, and the scope of standards used within the NZ Secure Web
Services Standard (NZ SWS). The scope will reflect the development of the
Standard and may change as required.
XML-Encryption
XML-Signature
WS-Security
WS-Trust
WS-Federation
WS-Privacy
WS-SecurityPolicy
WS-SecureConversation
WS-Policy
SOAP
SOAP
SOAP
SOAP
SOAP
WSDL
WSDL
TLS
TRANSPORT
SSL
WS-I BSP V1.1
NZ SWS Scope
Identity Token
Exchange
Included
Excluded
Symmetric Key Sessions
Policy
Definition
Policy
Exchange
WS* Token
Authentication
Figure 1 - WS-I Basic Security Profile
Department of Internal Affairs 20
B.6 OASIS Web services security specifications
It should be noted that the WS-I Basic Secure Profile 1.0/1.1 rests on specifications
contained in WS-Security. Other specifications such as WS-Trust, and WS-
SecureConversation do not have interoperability profiles defined as yet. Vendor
inconsistencies in implementation are possible.
a) WS-Security 1.1
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-
os-SOAPMessageSecurity.pdf
This describes enhancements to SOAP messaging to provide quality of protection
through message integrity, message confidentiality, and single message
authentication. These mechanisms can be used to accommodate a wide variety of
security models and encryption technologies. It also provides a general-purpose
mechanism for associating security tokens with messages. Also, WS-Security
describes how to encode X.509 certificates and SAML tokens as well as how to
include opaque encrypted keys. WS-Security includes extensibility mechanisms that
can be used to further describe the characteristics of the credentials that are
included within a message.
The 1.1 version of WS-Security contains extensions that are of significance. In
particular some performance enhancements may be possible using the extensions.
b) WS-SecureExchange (WS-SX)
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx
This is a banner title/grouping for a set of three standards produced by the OASIS
WS Secure Exchange Technical Committee. These include WS-SecurityPolicy, WS-
Trust and WS-Secure Conversation. The individual standards are nearly always
implemented and referred to directly and, therefore, the references to the WS-
SecureExchange standard are uncommon.
c) WS-SecurityPolicy
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/os/ws-securitypolicy-
1.3-spec-os.html
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-
1.2-spec-os.html
This describes the capabilities and constraints of the security (and other business)
policies on intermediaries and endpoints (for example. required security tokens,
supported encryption algorithms, or protected message parts) - thus providing a
standard for message exchange of these policies.
Department of Internal Affairs 21
d) WS-Trust
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html
This describes a framework for trust models that enables Web services to securely
interoperate - thus providing a standard for message exchange of trust data.
e) WS-SecureConversation
http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-
secureconversation-1.4-spec-os.html
This describes how to manage and authenticate message exchanges between
parties, including security context exchange and establishing and deriving session
keys.
f) WS-Security standards stack
WS-Secure Conversation
WS-Federation
WS-PolicyWS-Trust
WS-Security
SOAP, XML
WS-Security Policy
WS-Policy. Specifies the policy that a service provide can impose for a particular web service. The policy details what security capabilities and constraints the service exhibits. E.g. what type of encryption algorithm is supported and what parameters need to be encrypted. The policy can be used to discover security capabilities in much the same way as WSDL is used to discover functional capabilities.
WS-Security Policy 1.2. Specifies who is allowed to access a service and how, and restricts the kinds of authentication methods allowed and or the level of encryption required. It is a subset of WS-Policy, a more general way of expressing a services capabilities and limitations. Developed by IBM and Microsoft, WS-SecurityPolicy was officially standardised in July 2007 and should be supported by all vendors.
WS-Security 1.1. Describes how XML Encryption and XML Signature can be applied to SOAP documents or message. Supported by all vendors and used by all other WS-* standards involved in security.
WS-SecureConversation 1.3. A means of establishing a context for efficient encryption and integrity checks. The standard was ratified in March 2007, at which point IBM and Sun demonstrated implementations. Other vendors including Actional, BEA Systems, Cisco, Computer Associates, Layer & Technologies, Oracle, Reactivity, RAS Security and VeriSign have also pledged support.
WS-Federaition 1.1. Uses the security tokens transferred in WS-Trust to authenticate to Web Services, according to the service’s rules described in WS-SecurityPolicy. Note yet widely used, as SAML provides much of the same functionality. Its main advantage over SAML is Windows Support and tight integration with the WS* stack.
WS-Trust 1.3. Uses WS-Security to transfer tokens, such as passwords, digital certificates and SAML assertions. Non-SOAP Web Services have a partial equivalent in XKMS (XML Key Management Specification) and SAML.
Figure 2 – WS-Security standards
Department of Internal Affairs 22
Appendix C - Architectural patterns The appendix contains patterns of interest to the NZ Government agencies
described and documented in a consistent form.
Integrity, confidentiality and data origin authentication patterns
Fundamental to Web services security is the integrity and confidentiality of the
message. The following pattern and sub-patterns provide a model for implementing
integrity and confidentiality. The pattern also includes a message validation pattern
to address a number of issues around detecting and managing malicious content.
Message protection
C.1 Data confidentiality
C.2 Data integrity and origin authentication
C.3 Message Screening
Authentication patterns
Authentication for Web services can operate using one of three models; direct,
brokered and federated authentication.
Direct authentication is where Web service consumers and providers authenticate
directly to each other. For example, a service provider demands credentials from the
service consumer and then directly verifies them to authenticate the service
consumer. The opposite scenario is also true. Username and password or
certificates are commonly used. Direct authentication is often used by individual
applications and agencies.
Brokered authentication is where Web service consumers and providers
authenticate to each other using a mutually accepted third party identity provider.
Both service consumers and service providers authenticate to the identity provider.
The identity provider is acting as an identity broker between a community of service
consumers and providers. SAML tokens or certificates are commonly used. Brokered
authentication is used by agencies and third parties that wish to establish or join a
brokered identity domain. Brokered identity is supported across government by the
igovt SAML identity and logon service.
Federated authentication is a more complex model, which provides the ability for
identity communities to merge their identities into a single larger federated
community. Federation does not subsume identities into a third party identity store
like the brokered model. Federation merges identity domains allowing an identity in
one domain to be linked and then known to an identity store in another domain.
Department of Internal Affairs 23
Federated authentication requires specific implementation pattern support and
identity solution software. Federated identity is not supported by the igovt identity
service.
Only direct and brokered authentication patterns are included in this document.
Federated authentication is not in common use and requires shared policies and
shared software solutions which are not agreed.
C.4 Direct authentication
Brokered authentication
C.5 Brokered authentication security token service
C.6 Brokered authentication X.509 PKI
Non-repudiation patterns
Non-repudiation is primarily a business process and formal documented agreement
between parties about processes and procedure to be followed under specific
business situations. Web service non-repudiation capabilities provide technical
means of generating and validating evidence that can be used as part of a non-
repudiation implementation. This requires specific Web service implementation
patterns and technologies. The following patterns provide a model for implementing
Web service support for origin and delivery non-repudiation evidence creation and
verification.
C.7 Origin non-repudiation (ISO13888-1)
C.8 Delivery non-repudiation (ISO13888-1)
ISO also provide separate submission and transport non-repudiation patterns,
however these are not used by the Standard and are, therefore, not described in this
document.
Efficiency of security processing patterns
WS-Security provides mechanisms for securing individual messages in a message
exchange. Often interactions between a Web service provider and a Web service
consumer will result in multiple messages being exchanged. While each message
can be secured in isolation, it is more efficient to establish some form of context that
the Web service provider and Web service consumer share and use. Having a
shared context reduces the burden with respect to securing each message
exchanged.
C.9 Security Context Centralisation
Department of Internal Affairs 24
Message protection patterns Message protection can be divided into three main categories:
● Data confidentiality is the encrypting of message data so that unauthorised entities
cannot view the contents of the message
● Data integrity and origin authentication is the ability to verify that a message has
not changed in transit combined with the ability to identify and validate the origin of a
message.
● Message Screening is the ability to detect and reject malformed or malicious
content.
Department of Internal Affairs 25
C.1 Data confidentiality
Introduction
Use encryption to protect sensitive data that is contained in a message. Unencrypted
data, which is known as plaintext, is converted to encrypted data, which is known as
ciphertext. Data is encrypted with an algorithm and a cryptographic key. Ciphertext is
then converted back to plaintext at its destination.
The following pattern covers both use of symmetric and asymmetric cryptography.
Symmetric cryptography uses a shared secret known to both parties, whereas
asymmetric cryptography uses public key encryption where one key is used for
encryption and another is used for decryption. Asymmetric encryption adds
significant processing overhead and is only used where justified. It is possible to use
a combination of asymmetric and symmetric cryptography to reduce the overall
cryptographic processing overhead. This uses the more efficient symmetric
cryptography for high volume messaging and the less efficient asymmetric
cryptography for secure context negotiation to support the symmetric message
exchange.
Context
Data passes between a Web service consumer and a Web service provider,
sometimes through one or more intermediaries. Messages may also be kept in
repositories, such as message queues or databases. Some of the data within the
messages is considered to be sensitive in nature. There is a risk that an attacker can
gain access to sensitive data, either by eavesdropping on the network or accessing a
repository.
Problem
How do you protect data within a message from being disclosed to unintended
parties?
Forces
Any of the following conditions justify using the solutions described in this pattern:
a) Disclosure of sensitive data can result in loss or damage, such as identity theft,
lawsuits, loss of business, or regulatory fines. Any data that contains sensitive
information must be protected from unauthorised users.
b) Sensitive data may pass across the network. Sensitive data must be protected
from disclosure in transit. An eavesdropper can gain access to sensitive data
whenever it leaves a secure area (such as a protected memory space) or crosses a
non-secure communication line (such as a public network).
Department of Internal Affairs 26
c) Sensitive data may be persisted for short periods of time, such as in a message
queue, or over longer periods of time in a database or a file. Sensitive data must be
protected from disclosure in locations where it is persisted.
Participants
Data confidentiality involves the following participants:
Sender. The sender is the originator of a message. A client can send a request
message to a Web service, and a Web service can send a response message back
to a client that has sent a request message.
Recipient. The recipient is the entity that receives a message from the sender. A
Web service is the recipient of a request message that is sent by a client, and a
client is the recipient of a response message that it receives from a Web service.
The following sections separately describe the use of symmetric and asymmetric
cryptography to achieve confidentiality.
Symmetric cryptography process
With symmetric cryptography, both the sender and recipient share a single key that
is used to perform both encryption and decryption. Symmetric cryptography is
commonly used. It also provides data integrity when symmetric keys are used in
conjunction with other algorithms to create Message Authentication Codes (MACs).
PlainText PlainTextCipherText
Shared Secret Key
Encrypt Decrypt
SenderRecipient
Data Confidentiality using symmetric cryptography
Figure 2 - Data confidentiality using symmetric cryptography
Symmetric encryption involves the following steps:
1. The sender creates a ciphertext message by encrypting the plaintext message
with a symmetric encryption algorithm and a shared key.
2. The sender sends the ciphertext message to the recipient.
3. The recipient decrypts the ciphertext message back into plaintext with a shared
key.
Department of Internal Affairs 27
Symmetric algorithms currently in use include AES. These algorithms are designed
to perform efficiently on common hardware architectures. Symmetric cryptography is
comparatively simple in nature, because the algorithms used are straight forward.
However, before communication can occur, the sender and the recipient must
exchange a shared secret key. In some cases (such as TLS), asymmetric
cryptography can be used to encrypt the symmetric key for secure transmission to
other parties to ensure that the initial key exchange occurs over a secure channel.
This approach is also supported for message level security as described in the WS-
SecureConversation standard.
Asymmetric cryptography process
With asymmetric cryptography (also known as public key cryptography), the sender
encrypts data with a public key provided by the recipient, and then the recipient uses
their private key to decrypt the ciphertext. The encryption key and its matching
decryption key are referred to as a public/private key pair. In addition to providing
encryption public key cryptography can be used to provide digital signatures.
Public keys can be openly distributed to those who want to encrypt messages to the
recipient. Private keys are used to decrypt messages and must be kept secure and
confidential.
PlainText PlainTextCipherText
Recipients
Public Key
Encrypt Decrypt
SenderRecipient
Recipients
Private Key
Data Confidentiality using asymmetric cryptography
Figure 3- Data confidentiality using asymmetric cryptography
The process of confidential data exchange using asymmetric encryption involves the
following steps:
1. The sender creates a ciphertext message by encrypting the plaintext message
with an asymmetric encryption algorithm and the recipient’s public key.
2. The sender sends the ciphertext message to the recipient.
3. The recipient decrypts the ciphertext message back to plaintext using the private
key that corresponds with the public key that was used to encrypt the message.
Department of Internal Affairs 28
Resource overheads with asymmetric encryption
Asymmetric encryption requires more processing resources than symmetric
encryption. It is possible to reduce the overhead of processing individual
asymmetrically encrypted messages exchanges. Asymmetrically encrypted message
processing can be optimised by adding a one time random symmetric key to encrypt
a message and then asymmetrically encrypting the shared key only. This reduces
the sise of the data that is asymmetrically encrypted to improve performance.
In cases where more than one message exchange occurs between two parties in a
single session, a random shared secret can be negotiated between a sender and a
receiver. In this case, the first exchange includes a shared secret that is encrypted
asymmetrically and based on the shared secret, additional message exchanges are
performed symmetrically. Key derivation techniques are often used to add variability
to shared secrets that are used over multiple message exchanges. Establishing such
a session can be achieved by using either TLS for direct connections or by using
WS-SecureConversation message security for indirect connections.
Example
A bank publishes a Web service to provide business customers with the ability to
upload payroll account transfers. Direct deposit account information is considered
very sensitive for both the business and the customer. Compromising this
information can result in unauthorised account activity or disclosure of employee
salary information. For this reason, the bank requires that any messages containing
account data are encrypted as they pass between clients and the Web service to
provide data confidentiality.
Note: The information in the following sections is not intended to be comprehensive.
However, it does discuss many of the issues that are most commonly encountered
for this pattern.
Benefits
By blocking unauthorised parties from viewing messages, you can prevent financial
loss and legal liability due to the disclosure of sensitive information.
Liabilities
The liabilities associated with the data confidentiality pattern include the following:
Cryptography operations are computationally intensive and impact system
resource usage. This affects the scalability and performance of the application.
Key management, which safeguards encryption keys from being compromised,
can have significant administrative overhead. Factors that affect the administrative
complexity of key management include:
o The number and type of keys used.
o The type of encryption used (symmetric or asymmetric).
o The key management infrastructure in use.
Department of Internal Affairs 29
Security considerations
Security considerations associated with the data confidentiality pattern include the
following:
Encryption does not prevent data tampering. For example, a man-in-the-middle
attack can replace the bits in transit, which can cause the receiver to decrypt the
data to something other than the original plaintext. Without data integrity protection,
the receiver has no way of verifying that decrypted ciphertext is the same as the
original plaintext. For this reason, data encryption is often used in combination with
data integrity techniques.
If too much data is encrypted with the same symmetric key, an attacker can
intercept several messages and attempt to cryptographically attack the encrypted
messages, with the goal of obtaining the symmetric key. To minimise the risk of this
type of attack, you should consider generating session-based encryption keys with a
relatively short life span. Typically, these session keys are derived from a master
symmetric key, such as a shared identity secret. Usually, the session key is
exchanged by using asymmetric encryption during the initial interaction of a sender
and recipient. Session keys should be discarded and replaced at the end of each
session, or more frequently based on the amount of data or number of messages
that they are used to encrypt.
Much of the strength of symmetric encryption algorithms comes from the
randomness of their encryption keys. If keys originate from a source that is not
sufficiently random, attackers may narrow down the number of possible values for
the encryption key. This can make it possible for a brute force attack to discover the
key value from encrypted messages that the attacker has intercepted. For example,
a user password that is used as an encryption key can be very easy to attack
because user passwords are typically a non-random value of relatively small sise
that a user can remember without writing it somewhere.
You should use published, well-known current encryption algorithms that have
withstood sustained and significant attacks and scrutiny. Use of encryption
algorithms that have not been subjected to rigorous review by trained cryptologists
may contain undiscovered flaws that can be exploited by an attacker.
Department of Internal Affairs 30
C.2 Data integrity and origin authentication
Context
Data passes between a client and a Web service, sometimes through one or more
intermediaries. The data contained in the request message from the client influences
the Web service’s behaviour. There is a risk that an attacker could manipulate
messages in transit between the client and the Web service to maliciously alter the
behaviour of the Web service. Message manipulation can take the form of data
modification within the message, or substitution of credentials, to change the
apparent source of the request message.
Problem
How do you prevent an attacker from manipulating messages in transit between a
client and a Web service?
Forces
Any of the following conditions justifies using the solution described in this pattern:
An altered message can cause the message recipient to behave in an unintended
and undesired way. The message recipient should verify that the incoming message
has not been tampered with.
An attacker could pose as a legitimate sender and send falsified messages. The
message recipient should verify that incoming messages originated from a legitimate
sender.
As a prerequisite for non-repudiation.
Solution
Use of signatures to allow the recipient to verify that messages have not been
tampered with in transit (data integrity) and that they originate from the expected
sender (authenticity).
Security Concepts
Proof-of-possession is a value that a client presents to demonstrate knowledge of
either a shared secret or a private key to support client authentication.
Proof-of-possession using a shared secret can be established using the actual
shared secret, such as a user’s password, or a password equivalent, such as a
digest of the shared secret, which is typically created with a hash of the shared
secret and a salt value.
Proof-of-possession can also be established using the XML signature within a SOAP
message where the XML signature is generated symmetrically based on the shared
secret, or asymmetrically based on the sender’s private key.
Department of Internal Affairs 31
Participants
Data integrity and origin authentication involves the following participants:
Sender. The sender is the originator of a message. A client can send a request
message to a Web service, and a Web service can send a response message back
to the client that has sent the request message.
Recipient. The recipient is the entity that receives a message from the sender. A
Web service is the recipient of a request message sent by a client. A client is the
recipient of a response message that it receives from a Web service.
Signing process
Two types of signatures can be used to sign a message to provide data integrity and
origin authentication: symmetric and asymmetric.
The following discussion refers to both XML signatures and digital signatures. XML
signatures are used for SOAP message security with either a symmetric algorithm or
an asymmetric algorithm. Digital signatures are created explicitly with an asymmetric
algorithm and may or may not be used for SOAP message security.
The following sections separately describe the use of symmetric and asymmetric
signatures to achieve data integrity and origin authentication.
Department of Internal Affairs 32
Symmetric signature process
A symmetric signature is created by using a shared secret to sign and verify the
message. A symmetric signature is commonly known as a Message Authentication
Code (MAC). A MAC is created by computing a checksum with the message content
and the shared secret. A MAC can be verified only by a party that has both the
shared secret and the original message content that was used to create the MAC.
The most common type of MAC is a Hashed Message Authentication Code (HMAC).
The HMAC protocol uses a shared secret and a hashing algorithm (such as SHA-
256) to create the signature, which is added to the message. The message recipient
uses the shared secret and the message content to verify the signature by recreating
the HMAC and comparing it with the HMAC that was sent in the message.
Message Message & MAC
Shared Secret Key
Create MAC Verify MAC
SenderRecipient
Message
Data Integrity using symmetric signatures
Figure 4 - Data integrity using symmetric signatures
Signing a message using a symmetric signature involves the following steps:
1. The sender creates a MAC using a shared secret key and attaches it to the
message.
2. The sender sends the message and MAC to the recipient.
3. The recipient verifies that the MAC that was sent with the message by using the
same shared secret key that was used to create the MAC.
By signing with a shared secret, both data integrity and data origin authenticity are
provided for the signed message content. However, symmetric signatures are not
usually used to provide non-repudiation because shared secrets are known by
multiple parties. This makes it more difficult to prove that a specific party used the
shared secret to sign the message and is therefore insufficient as non-repudiation
proof.
Department of Internal Affairs 33
Asymmetric signature process
An asymmetric signature is processed with two different keys; one key is used to
create the signature and the other key is used to verify the signature. The two keys
are related to one another and are commonly referred to as a public/private key pair.
The public key is generally available and can be distributed with the message; the
private key is kept secret by the owner and is never sent in a message. A signature
that is created and verified with an asymmetric public/private key pair is referred to
as a digital signature.
To provide the recipient of a message with data integrity and origin authentication the
sender uses their private key to create a signature which the recipient can verify
using the sender’s public key. This preserves the secrecy of the sender’s private key
even though the sender may provide their public key as part of the message.
MessageMessage &
Digital Signature
Create Signature Verify Signature
SenderRecipient
Message
Senders
Private Key
Senders
Public Key
Data Integrity using asymmetric signatures
Figure 5- Data integrity using asymmetric signatures
Signing a message with an asymmetric signature involves the following steps:
1. The sender signs the message content using the sender’s private key and
attaches it to the message.
2. The sender sends the message and digital signature to the recipient.
3. The recipient verifies the digital signature using the sender’s public key that
corresponds with the private key that was used to sign the message.
The digital signature is created using an algorithm such as Elliptic Curve Digital
Signature Algorithm (DSA). ECDSA uses the public/private key pairs created for use
with the RSA algorithm to create and verify signatures.
For both signing and encryption purposes, asymmetric keys are often managed
through a Public Key Infrastructure (PKI). Information that describes the client is
bound to its public key through endorsement by a trusted party to form a certificate.
Certificates allow a message recipient to verify the private key in a client’s signature
using the public key in the client’s certificate.
Department of Internal Affairs 34
Typically, digital signatures are used to support requirements for non-repudiation.
This is because access to the private key is usually restricted to the owner of the
key, which makes it easier to verify proof-of-ownership.
Resource overheads with asymmetric encryption
Asymmetric signatures require more processing resources than symmetric
signatures. For this reason, asymmetric signatures are usually optimised by hashing
the message content and then asymmetrically signing the hash. This reduces the
sise of the data that the asymmetric operation is applied to.
In cases where more than one message is exchanged, it is also possible to first
exchange a high-entropy shared secret that is encrypted asymmetrically. Based on
the shared secret, additional message exchanges are secured symmetrically. Key
derivation techniques are often used to add variability to shared secrets that are
used over multiple message exchanges. It is important to remember that this type of
optimisation can remove the ability of asymmetric signatures to isolate which of the
two parties signed a message. Establishing such a session can be achieved by using
either TLS for direct connections or by using WS-SecureConversation message
security for indirect connections.
Example
A business customer at a bank may sign payroll transfers using his or her certificate
private key. The bank can then verify that the payroll transfer request came from the
correct business customer and that the message had not been tampered with in
transit between the business customer and the bank.
Note: The information in the following sections is not intended to be comprehensive.
However, it does discuss many of the issues that are most commonly encountered
for this pattern.
Benefits
The data integrity and origin authentication pattern makes it possible for the recipient
to detect whether a message has been tampered with and the origin of the message
can be traced to an identifiable source.
Liabilities
The liabilities associated with the data integrity origin authentication pattern include
the following:
Cryptographic operations, such as data signing and verification, are
computationally intensive processes that impact system resource usage. This affects
the scalability and performance of the application.
Key management, which is responsible for maintaining the integrity of keys, can
have a significant administrative overhead. Factors that affect the administrative
complexity of key management include:
Department of Internal Affairs 35
o The number and type of keys used.
o The type of cryptography used (symmetric or asymmetric).
o The key management infrastructure in use.
Security considerations
Security considerations associated with the data integrity origin authentication
pattern include the following:
If encrypted data within a message is being signed, you should ensure that the
signature within the message is also encrypted.
If too much data is encrypted with the same symmetric key, an attacker can
intercept several messages and attempt to cryptographically attack the encrypted
messages, with the goal of obtaining the symmetric key. To minimise the risk of this
type of attack, you should consider generating session-based encryption keys that
have a relatively short life span. Typically, these session keys are derived from a
master symmetric key such as a shared identity secret. Usually, the session key is
exchanged using asymmetric encryption during the initial interaction between a
sender and recipient. Session keys should be discarded and replaced at regular
intervals, based on the amount of data or the number of messages that they are
used to encrypt.
Much of the strength of symmetric encryption algorithms comes from the
randomness of their encryption keys. If keys originate from a source that is not
sufficiently random, attackers may narrow down the number of possible values for
the encryption key. This makes it possible for a brute force attack to discover the key
value of encrypted messages that the attacker has intercepted. For example, a user
password that is used as an encryption key can be very easy to attack because user
passwords are typically a non-random value of relatively small sise that a user can
remember it without writing it somewhere.
You should use recommended standard encryption algorithms.
Department of Internal Affairs 36
C.3 Message Screening
Context
A Web service interacts with other applications over a network. Incoming data may
be malformed and may have been transmitted for malicious purposes. There is also
a risk of injection attacks, where data from incoming messages is tampered with to
include additional syntax.
Problem
How do you protect Web services from malformed or malicious content?
Forces
Any of the following conditions justify using the solution described in this pattern:
Malicious content poses a risk to the Web service. An attacker can insert syntax
in a request message to cause the Web service or other downstream systems that
process the received data to behave in an undesirable manner. Web services that do
not require access control are especially susceptible because they have no means to
limit to a smaller, more trusted group, the number of clients that can access them.
There is a risk of attackers bypassing client validation techniques by using
alternative clients or by modifying data after it has left the client. Web services must
be designed to be autonomous and perform their own input validation instead of
trusting the validation that is performed in the client application.
An attacker can use malformed or oversised messages to launch a denial-of
service attack. Denial of service attacks can take advantage of the multiplier effect,
where a malformed or oversised message causes a disproportionate increase in the
use of resources, such as a server’s CPU time, memory usage, or database
connections.
Solution
Assume that all input data is malicious until proven otherwise, and use message
validation to protect against input attacks, such as injection, buffer overflows, and
other types of attacks. The message validation logic enforces a well-defined policy
that specifies which parts of a request message are required for the Web service to
successfully process it. It may validate the XML message payloads against an XML
schema (XSD) to ensure that they are well-formed and consistent with what the Web
service expects to process. The validation logic also measures the messages
against certain criteria by examining the message size, the message content, and
the character sets that are used. Finally and most importantly, the application must
defensively check any critical inputs to make sure that the values match
expectations. Any message that does not meet the criteria is rejected. For security
purposes, it is important that the error response to such invalid messages convey as
Department of Internal Affairs 37
little information as possible, so as to prevent attackers from gaining a better
understanding of the system. Valid clients of the system should obtain information
about rejected messages through controlled channels.
Participants
Message validation involves the following participants:
Web service consumer. The Web service that requests processing.
Web service provider. The Web service that processes requests and implements
the message validation logic.
Process
1. Send Request
2. Validate Message
3. Send Response
Web Service
Provider
Content Validation
Web Service
Consumer
Figure 6 – Message screening
The process for message screening is described in the following steps:
1. The Web service consumer sends a request message to the Web service
provider. The validation process itself is hidden from the Web service consumer.
2. The Web service provider validates the message. The message validation logic
makes a number of checks to validate the message. Checks can include:
Comparing the sise of the request against the maximum allowable sise that is
specified for request messages.
If the message is signed, verifying the signature to ensure that the message has
not been tampered with in transit.
Verifying that the message payload is well-formed and conforms to a predefined
schema, with acceptable data types and ranges of values.
Parsing the entire request message for malicious content. Potentially, malicious
content can be placed in either the SOAP message elements or in the message
payload, so both are checked.
Checking all critical input values at the application level to prevent unintended
behaviour from non-standard data.
3. If the request passes all the validation checks the Web service provider processes
the message and may issue a response to the Web service consumer.
Department of Internal Affairs 38
Note: The information in the following sections is not intended to be comprehensive.
However, it does discuss many of the issues that are most commonly encountered
for this pattern.
Benefits
The benefits of the content validation pattern include the following:
The Web service is protected from malformed and malicious content. This helps
protect against injection attacks, even for Web services that do not implement
access control.
The Web service performs validation independently of the client — it does not
accept messages simply because they have already been validated by the client.
Liabilities
The liabilities associated with the content validation pattern include the following:
Message validation logic does not process binary message content, such as
attachments. For message validation logic to process binary attachments, it needs to
be capable of recognising each type of binary attachment that it encounters to
ensure that they are free of malicious content. Specifying a maximum message size
helps to protect against injection attacks in binary attachments. However, validation
of binary data should be handled by antivirus filters.
If a message is encrypted with message layer security, it may not be possible to
inspect data for malicious content unless the message is decrypted beforehand or
the validation logic has access to the decryption key.
If data is protected by transport layer security, the entire channel is encrypted and
decrypted at end points. As a result, message validation cannot occur at any
intermediaries between those points.
Security considerations
Security considerations associated with the content validation pattern include the
following:
Message validation can help protect against denial of service attacks, but the
message validation logic must be very efficient when it conducts its validation
checks. Otherwise, the message validation logic may be a system bottleneck and
may itself become the target of a denial of service attack. Malformed content can
include very large messages, in some cases for the purposes of launching a denial
of service attack. Make the maximum message size large enough to allow legitimate
messages to be accepted but small enough to prevent attacks.
Using a validating parser and verifying the input message against its XML
Schema (XSD) result in a significant increase in CPU processing. And, even though
XML Schema (XSD) has the capability to specify data range validations and it
supports the use of regular expressions, many schemas use data types, such as
string, which do not prevent many forms of injection attacks. XML Schema is also
Department of Internal Affairs 39
limited to defining values in isolation, while the application often assumes
relationships between different values.
Instead of building the message validation logic into the Web service itself, it may
be beneficial to place it in an intermediary. This allows several Web services to use
the same intermediary, and it enables each Web service to dedicate its resources to
processing legitimate messages. It also ensures that invalid messages never reach
the Web service. However, using an intermediary in this way can create a single
point of failure, which may become a target of attack.
It is ultimately the responsibility of each application to be designed and tested to
assure that any form of unintended input does not cause the application to behave in
an undesirable manner. Message screening using external criteria such as message
length and XML Schema can be helpful, but if these are relied on in the application
design the reliance must be explicitly documented to assure it is enforced in
production environments. Even when XML Schema validation is used, the
application's use of input data will usually involve restraints and assumptions which
cannot be described in schema terms. As a simple example, consider what happens
when price and quantity fields are part of the input, and the product of the two
overflows the internal numeric representation. The overflow is clearly an error which
may have unintended results, but the input values may be individually within allowed
ranges.
The Web service may obtain data for response messages from external sources.
There is no guarantee that external data sources properly validate data. Passing
responses without message validation makes the Web service a potential ―carrier‖ of
malicious input from external data sources. Where required, consider validating Web
service response messages that are returned to the client.
Department of Internal Affairs 40
C.4 Direct authentication pattern
Context
A Web service consumer needs to access a Secure Web service. The Web service
requires the Web service consumer to present credentials for authentication.
Problem
How does the Web service verify the credentials that are presented by the Web service
consumer?
Forces
Any of the following conditions justify using the solution described in this pattern:
The credentials that the Web service consumer presents to the Web service are
based on shared secrets, such as passwords. Authentication of individual users is
often performed with passwords. Computers and applications often use higher quality
secrets that are more secure than passwords. The Web service consumer and the
Web service must exchange the shared secrets securely before interaction is possible.
The exchange of shared secrets must occur through an out-of-band mechanism.
The Web service is relatively simple, and does not require support for capabilities
such as single-sign on (SSO) or support for non-repudiation. In these circumstances
an effective, low cost solution that does not use an authentication broker may be
possible.
The Web service consumer and the Web service trust one another to manage
credentials securely. In this situation, both parties should consider the credentials as
equal in value to the information and services they protect. If either the Web service or
the Web service consumer manage the credentials in an insecure manner, neither
party can be sure that the mishandled credentials prove the identity of the user or
application.
When both the Web service consumer and service participate in a trust
relationship that allows them to exchange and validate credentials including
passwords, direct authentication can be performed.
The Web service can validate credentials from the Web service consumer against
an identity store.
The Web service must have direct access to the identity store, including appropriate
permissions for accessing identity information. An example of when this might be
appropriate is where Web service consumer applications and the service are able to
Department of Internal Affairs 41
establish credentials prior to the Web service consumer using the Web service’s
capabilities. An example is where the Web service wraps a legacy application that
incorporates a custom authentication implementation that requires a user name and
password to authenticate the Web service consumer using information from a
database.
Solution
Use direct authentication where the Web service acts as an authentication service to
validate credentials from the Web service consumer. The credentials, which include
proof-of-possession that is based on shared secrets, are verified against an identity
store.
Participants
Web service consumer. The Web service consumer accesses the Web service. The
Web service consumer provides the credentials for authentication during the request to
the Web service.
Web service provider. The Web service that requires authentication of the Web service
consumer.
Identity Store. The entity that stores a Web service consumer’s credentials.
Process
1. Send Request 2. Authentication Request
5. Send ResponseWeb Service
ConsumerWeb Service
Provider
4. Authentication
Response
Direct Authentication
Identity
Store
3. Validate
Credentials
1. The Web service consumer sends a request to the Web service provider, attaching
credentials to the request message.
2-4. The Web service provider validates the credentials through their identity store.
5. The Web service returns a response to the Web service consumer. (This step is
optional.)
Figure 7 - Direct authentication
Department of Internal Affairs 42
Note: The information in the following sections is not intended to be comprehensive.
However, it does discuss many of the issues that are most commonly encountered for
this pattern.
Benefits
The benefits of the direct authentication pattern include the following:
Uncomplicated model for authenticating Web service consumers without the need
for an authentication broker.
If the shared secret between a Web service consumer and Web service provider
is compromised only the relationship between those two parties is compromised.
Direct authentication works with any infrastructure used to provide credential
management.
Liabilities
The liabilities of the direct authentication pattern include the following:
Requires authentication for every call. The process of authenticating the Web
service consumer on every call can have a negative impact on performance. It is
possible to cache the user name and password; however, that is not a recommended
procedure.
Direct authentication does not provide single sign on capabilities. Without single
sign on, the Web service consumer may be forced to authenticate prior to every Web
service call or to cache the user’s credentials within the application. If the user’s
credentials include a password, caching the password is not recommended because it
may pose a security risk.
The decentralised nature of direct authentication requires that the trust
relationship be managed between each point in the communication. Point to point trust
relationship such as this will provide maintenance issues for the credentials or shared
secrets.
If a Web service consumer calls a Web service frequently, the use of direct
authentication can increase latency, because the Web service typically authenticates
against a remote identity store.
Data ownership and synchronisation issues can occur if each Web service has its
own identity store with which to authenticate for the same Web service consumer. This
requires the Web service consumer’s credentials to be duplicated across multiple
identity stores.
Security considerations
Department of Internal Affairs 43
Security considerations associated with the direct authentication pattern include the
following:
An attacker can impersonate the Web service consumer if he or she intercepts
the Web service consumer’s shared secret. The identity secret may be obtained if it is
unprotected in transit or successfully guessed offline. Encryption should be used to
provide data confidentiality for this data.
A shared secret is sensitive data and must be secured whenever it is persisted —
even if it will be held for only a short time in a message queue. Shared secrets must be
protected when stored in an identity store. If an attacker gains unauthorised access to
an identity store that stores passwords in plaintext, all passwords in the identity store
are immediately compromised. This allows the attacker to impersonate any user. Most
authentication services such as Lightweight Directory Access Protocol (LDAP) -
enabled directory services use identity stores that store passwords as either hashed,
encrypted, or both. However, for custom identity stores such as a database, it is
required to ensure that the passwords are protected. Although a brute force or pre-
computed dictionary attack is possible against a hashed password, hashing the
passwords in the database will protect them from immediate disclosure in the event
that an attacker gains access to them. Using cryptographic salt in the hash further
increases the difficulty of breaking passwords based on the hashed values.
If a Web service consumer calls a Web service after a user has authenticated, it
must cache the username and password locally for presentation on subsequent calls to
the Web service for direct authentication. Caching secrets, such as passwords,
increases the risk of disclosure if an attacker is able to gain access to the cache or
flush the contents of the cache to an accessible location. The cache mechanism
should be secured so that its confidentiality and integrity can be maintained to prevent
disclosure or tampering. If the Web service consumer is a Web application in a Web
farm, consider brokered authentication instead of direct authentication.
Requirements for use of this pattern
a) Passwords for medium/high value services MUST be encrypted (or hashed) when
stored.
b) Passwords for low value services SHOULD be encrypted (or hashed) when
stored.
c) This pattern MAY be used for low value services (i.e those handling public
information) where authentication is used as a mechanism to avoid denial of service
attack.
d) This pattern is NOT RECOMMENDED for use to authenticate individual users for
low or medium value services.
e) This pattern is NOT RECOMMENDED for medium/high value agency to agency
interactions over a public network.
Department of Internal Affairs 44
Reality checks
This pattern is commonly implemented across NZ government, typically for internal
services accessed within the secure application zones of a network.
Most databases support storage of encrypted username/password combinations.
However the encryption algorithm is often easily available and this leads to potential
password guessing attacks by comparing network traffic with common passwords.
Traffic over internal networks to the identity store may be vulnerable to interception
depending on the database and protocol used.
Department of Internal Affairs 45
Brokered authentication
Brokered authentication patterns provide an agreed common source of authentication
credential validation for both the Web service provider and the Web service consumer.
Typically brokered authentication is provided by a security token. This pattern replaces
the direct trust relationship between the Web service consumer and Web service
provider with brokered relationship using a third party authentication service.
In summary, the third party authentication service authenticates the Web service
consumer and issues a security token that the Web service provider can use to
authenticate the Web service consumer. The security token is always verified, but the
Web service provider may not need to interact with the authentication service to
perform the verification. The security token can contain proof of a relationship between
the Web service consumer and the third party authentication service, which can be
used by the Web service provider to authenticate the Web service consumer.
There are other security considerations that may require brokered rather than direct
authentication; message protection requirements may dictate the use of brokered
authentication rather than direct authentication.
Brokered authentication is supported by security token profiles in WS-Security. These
are: X.509, KerberosToken, and a custom security token issued by a Security Token
Service (STS).
The following diagram provides an overview of the Security Token Service Profile and
X.509 Profiles of the brokered authentication Pattern.
Figure 8 - Brokered authentication overview
Department of Internal Affairs 46
C.5 Brokered authentication: Security Token Service
(Security Token Service SAML token profile)
Context
A Web service provider needs to authenticate a Web service consumer. The Web
service consumer will present a credential to the Web service provider, who must
authenticate the Web service provider or the user the service is requested on behalf of.
Problem
How does the Web service verify the credentials presented by the client?
Web service providers need to be able authenticate service consumers without
needing to store unique consumer credentials for every individual consumer with which
they interact for every individual service they provide.
Web service consumers need to be able to authenticate to numerous service providers
and individual services without needing to store and manage unique credentials for
every individual service provider and service they interact with.
Web service consumers need to be able to be able to act on behalf of individuals and,
without brokered authentication, every Web service provider has to implement a
separate personal authentication solution.
Forces
Any of the following conditions justifies using the solution described in this pattern:
The environment includes multiple organisational boundaries or autonomous
security domains. The authentication broker must be able to issue security tokens that
can be used across organisational boundaries.
The client and the Web service do not trust each other. The client and the Web
service may not trust one another to manage or exchange shared secrets securely.
Establishing trust directly between a client and Web service could require offline
interactions that can hinder clients and services from interacting dynamically.
The authentication broker might be offline or unavailable on some occasions. The
Web service must be able to validate authentication credentials when the
authentication broker is not available. This ensures that the Web service can continue
to process requests, even if the authentication broker becomes unavailable.
Clients that require authentication are implemented on a variety of platforms
within the organisation, and interoperability is required between those platforms. Using
Department of Internal Affairs 47
a standards-based mechanism for authentication helps ensure interoperability between
different platforms.
The organisation may need to trace particular actions to a specific client or
service. A record of transactions allows an organisation to provide evidence that a
particular action was requested and/or performed. This could be useful if a user denies
that he or she performed an action or if a client needs to verify that a service has
performed a specific task.
Web service consumers requiring authentication are implemented on a variety of
platforms within the organisation, and interoperability is required between those
platforms. Using a standards based mechanism for authentication helps ensure
interoperability between different platforms.
Solution
An authentication broker is used to provide a common access control infrastructure for
a group of applications. The authentication broker negotiates trust between Web
service consumer applications and Web service provider application; this removes the
need for a direct relationship. The authentication broker will issue signed security
tokens that can be used for authentication.
The Security Token Service (STS) is trusted by both the Web service consumer and
the Web service to provide interoperable security tokens.
The Web service consumer sends an authentication request, with accompanying
credentials, to the Security Token Service. The Security Token Service verifies the
credentials presented by the Web service consumer, and then in response, it issues a
security token that provides proof that the Web service consumer has authenticated
with the Security Token Service. The Web service consumer presents the security
token to the Web service. The Web service verifies that the token was issued by a
trusted STS, which proves that the Web service consumer has successfully
authenticated with the Security Token Service.
The protocol used for issuing security tokens is based on WS-Trust. It describes a
protocol used for issuance, exchange, and validation of security tokens. WS-Trust
provides interoperability by defining a protocol for issuing and exchanging security
tokens, based on token format, namespace, or trust boundaries.
In WS-Trust, the type of message sent to an Security Token Service to request
issuance of a security token is known as a Request Security Token (RST) message.
The RST message contains credentials for the Web service consumer to be
authenticated, such as the user ID and password contained in a UsernameToken. The
response message from the Security Token Service is known as a Request Security
Token Response (RSTR) message. The RSTR contains a security token, such as an
XML Security Assertion Markup Language (SAML). For more information about WS-
Trust, see Web services Trust Language (WS-Trust) on OASIS.
Department of Internal Affairs 48
SAML tokens
SAML (Security Assertion Markup Language) tokens are standards-based XML tokens
that are used to exchange security information, including attribute statements,
authentication decision statements, and authorisation decision statements. SAML
tokens are also extensible; this means the schema of the token can be extended to
meet additional requirements.
SAML tokens are important for Web service security because they provide cross-
platform interoperability and a means of exchanging security information between Web
service consumers and services that do not reside within a single security domain.
They can be used as part of an SSO solution allowing a Web service consumer to talk
to services running on disparate technologies.
For more information about the SAML 1.1 and 2.0 specifications, including the protocol
for request and issuance of SAML tokens, see the OASIS Web site. In addition, the
Authentication Standard ―NZ SAMS‖ details the use of SAML for browser based
authentication.
Participants
Brokered authentication with Security Token Service involves the following
participants:
Web service consumer. The Web service consumer accesses the Web service and
provides the credentials for authentication.
Security Token Service. The Security Token Service is a Web service accessible
authentication service that validates the Web service consumers credentials. The
Security Token Service can issue a security token to a successfully authenticated Web
service consumer.
Web service provider. The Web service provider supplies the Web service that
requires authentication of a Web service consumer.
Department of Internal Affairs 49
Process
A security token is issued to the Web service consumer by the Security Token Service
and then used to authenticate with a Web service, which then returns a response to
the Web service consumer.
The following steps describe Security Token Service token issuance and
request/response process:
1. The Web service consumer initialises and sends authentication request to the
Security Token Service.
The authentication request to the Security Token Service is in the form of an Request
Security Token(RST) message. This step can be performed by presenting the Web
service consumer’s identifier and proof-of-possession (such as user name and
password) directly to the Security Token Service or by using a token issued by an
authentication broker (such as an X.509 digital signature, or for this profile a SAML
token).
The RST message contains a security token that holds the Web service consumer’s
credentials, which are required to authenticate the Web service consumer. Claims in
the Web service consumer’s credentials, such as a password, may be sensitive in
nature, so it is very important to secure the RST. The specific security mechanism
used for securing the RST depends on the relationship between the Web service
consumer and the Security Token Service. For example, the Web service consumer
and Security Token Service may use X.509 certificates to sign and encrypt messages
sent between them.
Figure 9 - Brokered authentication STS
Department of Internal Affairs 50
2. The Security Token Service validates the Web service consumer’s credentials.
After the Security Token Service determines that the Web service consumer’s
credentials are valid, it may also decide whether to issue a security token for the
authenticated Web service consumer. For example, the Security Token Service may
have a policy where it issues tokens only for users who belong to a specific role or for
valid X.509 certificates that can be validated through a specific trust chain.
3. The Security Token Service issues a security token to the Web service consumer.
If the Web service consumer’s credentials are successfully validated, the Security
Token Service issues a security token (such as a SAML token) in an RSTR message
to the Web service consumer; typically, the security token contains claims related to
the Web service consumer. The security token is usually signed by the STS; when the
security token is signed by STS, the service can confirm that the token was issued by
the Security Token Service and that the security token was not tampered with after it
was issued.
4. The Web service consumer initialises and sends a request message to the
service.
After the Web service consumer receives a security token from the STS, it initialises a
request message that includes the issued security token, and then it sends the request
message to the service.
5. The service validates the security token and processes the request.
The security token is validated by the service to verify that the token was issued by the
trusted Security Token Service and that the token was not tampered with after it was
issued. After the token is validated by the service, it is used to establish security
context for the Web service consumer, so the service can make authorisation
decisions or audit activity.
6. (Optional) The service initialises and sends a response message to the Web
service consumer. A response is not always required. Frequently, the response
message contains sensitive data, so it should be secured.
A Web service consumer may also specify the scope of the request for a security token
to the Security Token Service. Scope is a value that identifies the target of the Web
service consumer; it can be as granular as a single operation of the Web service or as
broad as an application domain. The token issued by the Security Token Service can
contain usage constraints that correspond to the scope of the request.
Scope can be used to provide resource level authorisation, with the Security Token
Service comparing the value in the scope to a list of Web service consumers that are
authorised to access the target.
Note: The information in the following sections is not intended to be comprehensive.
However, it does discuss many of the issues that are most commonly encountered for
this pattern.
Department of Internal Affairs 51
Benefits
The benefits of using the brokered authentication: Security Token Service (STS)
pattern include the following:
Authentication does not require a direct relationship between every client and
service.
Provides a shared authentication credential that can reduce the complexity of the
many to many relations between service consumers and service providers. Removing
the need for a service consumer to hold unique credentials for every service provider
and service they interact with and vice versa for service providers. Multiple services or
service providers may accept the Security Token Authentication
Security Tokens normally have a short life span and automatically expire.
Provides a standardised approach to authentication that scales and
accommodates change.
A flexible solution for exchanging one type of security token for another to
accomplish a variety of goals in a Web service environment, such as authentication,
authorisation, and exchanging session keys.
The solution is not dependent on any one mechanism, such as X.509 to secure
messages. This makes it easier to enable different authentication protocols to
interoperate, by adding a level of abstraction on top of existing protocols.
Authentication can occur over well known Internet firewall-friendly ports through
well-known protocols (for example, HTTP/HTTPS over port 80/443).
Liabilities
The layer of abstraction provided by the Security Token Service means that the
Security Token Service must use another underlying security protocol to provide
functionality such as authentication and authorisation. This can make the Security
Token Service a more difficult solution to implement, particularly in cases where a
custom solution is used.
Security considerations
Request and response messages between the Web service consumer and the
Security Token Service and between the Web service consumer and the service may
also be susceptible to message replay attacks if communication is secured at the
message layer.
Request and response messages between the Web service consumer and the
Security Token Service often contain sensitive information, such as user passwords
Department of Internal Affairs 52
and session encryption/signature keys, so they should be protected using data
encryption and data origin authentication.
Request messages between the Web services consumer and the Web service
provider must use encryption to prevent exposure and possible misuse of the Security
Token.
Department of Internal Affairs 53
C.6 Brokered authentication: X.509 PKI
Context
A Web service provider needs to authenticate a Web service consumer. The Web
service consumer will present a credential to the Web service provider, who must
authenticate the Web service provider or the user who has requested the service.
Problem
How does the Web service verify the credentials presented by the client?
Web service providers need to be able authenticate service consumers without
needing to store unique consumer credentials for every individual consumer with which
they interact for every individual service they provide.
Web service consumers need to be able to authenticate to numerous service providers
and individual services without needing to store and manage unique credentials for
very individual service provider and service they interact with.
Web service consumers need to be able to be able to act on behalf of individual person
and without brokered authentication every Web service provider has to implement a
separate personal authentication solution.
Forces
Any of the following conditions justifies using the solution described in this pattern:
The environment includes multiple organisational boundaries or autonomous
security domains. The authentication broker must be able to issue security tokens that
can be used across organisational boundaries.
The client and the Web service do not trust each other. The client and the Web
service may not trust one another to manage or exchange shared secrets securely.
Establishing trust directly between a client and Web service could require offline
interactions that can hinder clients and services from interacting dynamically.
The authentication broker might be offline or unavailable on some occasions. The
Web service must be able to validate authentication credentials when the
authentication broker is not available. This ensures that the Web service can continue
to process requests, even if the authentication broker becomes unavailable.
Clients that require authentication are implemented on a variety of platforms
within the organisation, and interoperability is required between those platforms. Using
a standards-based mechanism for authentication helps ensure interoperability between
different platforms.
Department of Internal Affairs 54
The organisation may need to trace particular actions to a specific client or
service. A record of transactions allows an organisation to provide evidence that a
particular action was requested and/or performed. This could be useful if a user denies
that he or she performed an action or if a client needs to verify that a service has
performed a specific task.
Web service consumers requiring authentication are implemented on a variety of
platforms within the organisation, and interoperability is required between those
platforms. Using a standards based mechanism for authentication helps ensure
interoperability between different platforms.
Solution
Use brokered authentication with X.509 certificates issued by a certificate authority
(CA) in a public key infrastructure (PKI) to verify the credentials presented by the
requesting application. The Web service consumer attaches credentials (or a reference
to credentials) to the request message and digitally signs the message with the Web
service consumer’s private key. When a Web service provider receives the message, it
uses the Web service consumer’s public key, which is included with the X.509
certificate, to validate the signature. Additional validation may be required to ensure
that the X.509 certificate has not expired and was issued by a CA that the service
trusts.
You can use mutual authentication to be sure that each party using X.509 is who they
claim to be. With mutual authentication, the Web service consumer authenticates the
Web service provider and the Web service provider authenticates the Web service
consumer. For authentication with X.509 certificates, each party must be able to verify
a piece of signed data provided by the other party with that party’s X.509 certificate.
Alternatively, if only one party has an X.509 certificate, shared keys can be combined
with X.509 certificates to provide mutual authentication.
Participants
Brokered authentication with X.509 certificates issued by a certificate authority in a PKI
involves the following participants:
Certificate authority (CA). A Certificate Authority is an authentication broker that is
responsible for authenticating clients and issuing valid X.509 certificates.
Certificate store. This is where the X.509 certificates are located.
Web service consumer. The Web service consumer accesses the Web service.
The Web service consumer provides the credentials for authentication during the
request to the Web Service Provider.
Web service provider. The service provider that requires authentication of a Web
service consumer or the individual the Web service consumer is acting on behalf of..
Department of Internal Affairs 55
Process
A mutually trusted CA must issue an X.509 certificate before brokered authentication
using X.509 can complete. An X.509 certificate can be obtained in one of the following
ways:
Purchase an X.509 certificate from a public CA.
Configure a PKI server, such as OpenSSL or Windows Certificate Services, to
create an X.509 certificate, and then use the PKI CA to sign the certificate.
Use a tool such as keytool or MakeCert to create a self-signed certificate (this is
not suitable for production purposes).
After an X.509 certificate is issued, local repositories, such as a machine certificate
store, are used to store information about the X.509 certificate. The actual process of
issuing and distributing X.509 certificates is beyond the scope of this pattern.
1. Send Request 2. Validate Certificate
4. Send ResponseWeb Service
Consumer
Web Service
Provider
3. Validate Signature
Certificate
Authority
Brokered Authentication X.509 PKI
Figure 10 - Brokered authentication X.509
The following steps describe the process of authentication using an X.509 certificate:
1. The Web service consumer sends a request message to the Web service provider.
The message includes the Web service consumer’s credentials, signed with the private
key that is paired with the public key in the Web service consumer’s X.509 certificate.
The Web service consumer can also attach its X.509 certificate to the message if the
Web service provider does not store or have access to the X.509 certificates out of
band. If the X.509 certificate is not attached, the Web service consumer attaches a
certificate identifier to the request message so that the Web Service Provider can
retrieve the Web service consumer’s X.509 certificate from a certificate repository and
verify the message signature.
2. The Web service provider validates the certificate, by performing a number of
checks, including:
Department of Internal Affairs 56
Verifying that the certificate has not expired. If the expiration date in the certificate
is past the current date, then the certificate is not valid.
Verifying that the certificate is internally consistent. The Web service provider
checks that the data in the certificate has not been tampered with by verifying the
certificate contents against the signature of the issuing CA.
Verifying the issuing CA of the Web service consumer’s X.509 certificate. This is
done by comparing the issuer signature on the Web service consumer’s X.509
certificate with the X.509 certificate of the issuing CA. For this step to be of any value
to either party, the CA that issued the Web service consumer’s X.509 certificate must
be trusted by both the Web service consumer and Web service provider.
Verifying that the issuing CA has not revoked the certificate. The Web service
provider checks this by making sure that the X.509 certificate does not appear on a
certificate revocation list (CRL) published by the issuing CA. The Web Service Provider
can check the revocation status of the certificate by directly accessing it from the CA or
by checking against a CRL that was previously downloaded from the issuing CA to the
certificate repository used by the Web service provider to look up X.509 certificates.
3. The Web service provider uses the public key in the Web service consumer’s X.509
certificate to verify the Web service consumer’s signature. This allows the Web service
provider to authenticate the Web service consumer and ensure that the signed data
has not been tampered with after the message was signed.
4. (Optional) The Web service provider may send a response back to the Web service
consumer.
Note: The information in this section is not intended to be comprehensive. However, it
does discuss many of the issues that are most commonly encountered for this pattern.
Benefits
The benefits of using the brokered authentication: X.509 PKI pattern include the
following:
Authentication can occur over well known Internet firewall-friendly ports through
well-known protocols (for example, HTTP/HTTPS over port 80/443).
X.509 certificates can be used to authenticate clients and protect messages
across organisational boundaries and security domains because the X.509 certificates
are based on a broadly accepted standard. PKI using X.509 certificates has the
capacity to establish a common basis of trust beyond the scope of individual
organisations.
The X.509 CA supports renewal and revocation of X.509 certificates, as follows:
o An agent, acting on the client’s behalf, can renew an X.509 certificate to extend
the life time of the certificate. When an X.509 certificate is renewed, a new copy of the
Department of Internal Affairs 57
certificate is generated with a new expiration date, sometimes along with a
corresponding new public/private key pair.
o X.509 certificates may be revoked if any of the client’s information in the X.509
certificate has changed or if the X.509 certificate’s private key has been compromised.
X.509 certificates can be distributed openly and used by anyone to encrypt
messages to a client or to verify the digital signature of the client.
Digital signatures provide a means of supporting non-repudiation. This is because
access to the private key is usually restricted to the owner of the key, which makes it
easier to verify proof-of-ownership.
Authentication does not require a direct relationship between every client and
service.
o Provides a shared authentication credential that can reduce the complexity of the
many to many relations between service consumers and service providers. Removing
the need for a service consumer to hold unique credentials for every service provider
and service they interact with and vice versa for service providers. Multiple services or
service providers may accept the Security Token Authentication
o Provides a standardised approach to authentication that scales and
accommodates change.
Liabilities
The liabilities associated with the brokered authentication: X.509 PKI pattern include
the following:
Private keys need to be stored securely (such as on a smart card or your
computer) and are therefore not as portable as passwords. An attacker could use a
private key to impersonate the client. Therefore, you must make sure that the private
key is not compromised.
Generating and verifying digital signatures in X.509 is computationally intensive. If
the client sends frequent request messages to the service during a normal interaction,
you should consider a means to optimise communication between the two parties,
such as secure conversation.
Certificates by themselves are not well suited to provide role-based security,
because role assignment tends to change relatively frequently and X.509 certificates
typically have a long life time. However, you can supplement X.509 certificate
authentication with a role store to provide more fine-grained authorisation capabilities.
One possible solution is to combine X.509 authentication with a Lightweight Directory
Access Protocol (LDAP) directory or Active Directory with certificate mapping enabled.
Organisations could require additional infrastructure to support an X.509 PKI. The
benefits gained from using an X.509 PKI must be compared with the investment
required to use it.
Department of Internal Affairs 58
Security considerations
Security considerations associated with the brokered authentication: X.509 PKI pattern
include the following:
It is critical to safeguard the private key associated with the X.509 certificate. If
the private key is compromised, the integrity of the corresponding X.509 certificate is
violated because another entity besides the client is capable of generating digital
signatures that represent the client’s identity. If a private key is compromised, the CA
can revoke the X.509 certificate, which causes it to become unusable for encryption
and digital signatures.
The life time of an X.509 certificate is considerably greater than that of other
authentication broker token types. Most tokens from an authentication broker expire
minutes or hours from their time of issue, whereas an X.509 certificate can be valid for
several months.
Regardless of whether an X.509 certificate is renewed or revoked and a new
X.509 certificate is re-issued, the X.509 certificate should use a newly generated
public/private key pair. For existing X.509 certificates that are being renewed, this is
known as re-keying the X.509 certificate.
Only one copy of the client’s X.509 certificates private key should exist when it is
used to support non-repudiation through digital signatures. This private key should be
accessible to the client only.
If private keys are centrally managed — for example, by using a key escrow and
the centralised store is compromised, you may not be able to use digital signatures to
strongly attribute an action to a specific party.
In some cases, after a service has authenticated a client, it will need to authorise
the client based on the client identity. The service must be able to either recognise the
client individually or verify that the client belongs to a limited population. The service
can accomplish this in one of the following ways:
o By defining a policy that only allows requests to be processed that are signed by
specific X.509 certificates.
o By requiring verification of X.509 client certificates against a very restricted trust
chain. This allows you to closely regulate the population of clients from which the
server will accept requests.
Messages that are signed and encrypted with X.509 certificates are susceptible to
surreptitious forwarding attacks. In this type of attack, the recipient of a signed and
encrypted message decrypts the message, encrypts it using a third-party’s public key,
and then sends it on to that third party with the original signature still in the message.
In this case, the message can appear as though it was sent to the third party from the
original sender. To mitigate this type of attack, the original sender can sign some
information that binds the message to the intended recipient, such as the WS-
Addressing headers that specify the intended recipient of the message.
Department of Internal Affairs 59
If an authentication broker is compromised, the integrity of the trust that the
broker provides is also compromised. If a CA is compromised, an attacker could issue
certificates to himself/herself to act as a valid client within the CA’s trust chain. An
attacker could use these certificates to perform malicious actions while posing as a
trusted client.
Standard X.509 certificate handling implicitly trusts both a relatively small number
of root certificate authorities and a much larger number of certificate authorities
authorized by those root authorities. Some of these second-tier certificate authorities
are known to have had their private keys stolen, so from a security standpoint the
whole system is questionable. Because of this, the use of public X.509 certificate
authorities is NOT RECOMMENDED for medium/high value services. Private
certificate authorities controlled by the agency providing the service should instead be
used, and both service consumers and service providers should be configured to reject
any certificates not issued by the private authority.
Department of Internal Affairs 60
C.7 Origin non-repudiation
This pattern looks at origin non-repudiation mechanisms using cryptographic
techniques.
This pattern addresses the Web services related aspects of three phases of non-
repudiation:
evidence generation;
evidence transfer, storage and retrieval;
evidence verification.
The fourth phase of non-repudiation, that of dispute arbitration, is outside the scope
this pattern.
Context
The goal of a non-repudiation service is to generate, collect, maintain, make available
and verify evidence concerning a claimed event or action in order to resolve disputes
about the occurrence or non-occurrence of the event or action.
Non-repudiation services establish evidence; evidence establishes accountability
regarding a particular event or action. The entity responsible for the action, or
associated with the event, with regard to which evidence is generated, is known as the
evidence subject.
Non-repudiation mechanisms provide protocols for the exchange of non-repudiation
tokens specific to each non-repudiation service.
Non-repudiation tokens consist of secure envelopes and/or digital signatures and,
optionally, additional data:
Secure envelopes are generated by an evidence generating authority using
symmetric cryptographic techniques.
Digital signatures are generated by an evidence generator or an evidence
generating authority using asymmetric techniques.
Non-repudiation tokens can be stored as non-repudiation information that can be used
subsequently by disputing parties or by an adjudicator to arbitrate in disputes.
Problem – origin non-repudiation
The service needs to protect against the false denial of being both the creator (the
author of the content) of a message and the sender of the message. The service may
be provided by the sender itself or by an authority acting on behalf of the sender.
Department of Internal Affairs 61
Forces
Non-repudiation is always based upon a formal agreement between parties that
specifies the process, procedures, evidential records and timeframes applicable.
Depending on the non-repudiation formal agreement in effect for a specific application,
and the legal environment within which the application operates, additional information
may be required to complete the non-repudiation information, for example:
evidence including a trusted time-stamp provided by a time-stamping authority,
evidence provided by a notary which provides assurance about data created or
the action or event performed by one or more entities.
Non-repudiation can only be provided within the context of a clearly defined security
policy for a particular application and its legal environment.
The encryption and signing mechanisms will be based upon keys that have a finite life
– after which they will degrade and become less reliable and secure, and hence
inadmissible as evidence. For example, certificates used will expire or be subject to
security problems.
Solution
The following solution diagram shows origin non-repudiation between a sender and a
recipient. In a Web service context both the Web service consumer and the Web
service provider can be either the Sender or Recipient. i.e. A Web service consumer
can be the sender of a request and a Web service provider can be the sender of a
response.
MessageMessage &
Digital Signature
Create SignatureVerify Signature
SenderRecipient
Senders
Private Key
Senders
Public Key
Timestamp
Persistent
Storage
Immediate and delayed
Non-repudiation
Processing
Origin Non-repudiation
1.2.
3.
Figure 11- Origin Non-repudiation
1. The Web service message content is signed using the senders private key.
2. The recipient verifies the senders signature using the senders public key.
3. The recipient retains the whole message including the signature.
Department of Internal Affairs 62
Security factors and risks
Evidence is represented by non-repudiation tokens consisting of either secure
envelopes or digital signatures. Both are based on cryptographic check values
generated by either symmetric or asymmetric cryptographic techniques, respectively.
Using certificate-based signatures, the non-repudiation token consists basically of the
signed message (which consists of the message and the signature) and its public key
certificate(s). If the public key certificate is not provided with the digital signature, it has
to be available to the appropriate parties.
Depending on the basic mechanism used for generating non-repudiation tokens, the
following requirements hold for the entities involved in a non-repudiation exchange.
The entities of a non-repudiation exchange shall trust the same trusted third Party
(TTP), which may be composed of several independent TTPs bound by non-
repudiation agreements.
The signature key belonging to an entity must be kept secret by that entity.
The digital signature mechanism used shall satisfy the security requirements
specified by the policy.
Prior to the generation of evidence, the evidence generator must know which
non-repudiation policies the evidence shall be generated in accordance with, what type
of evidence is to be generated, and which mechanisms are to be used to verify the
evidence.
The mechanisms for generating or verifying evidence must be available to the
entities of the particular non-repudiation exchange, or a trusted authority must be
available to provide the mechanisms.
The evidence generator and verifier may have access to a trusted time stamping
or notary facility.
Standards
ISO 13888-1
Department of Internal Affairs 63
C.8 Delivery non-repudiation
This pattern looks at non-repudiation mechanisms using cryptographic techniques.
This pattern addresses the Web services related aspects of three phases of non-
repudiation:
evidence generation;
evidence transfer, storage and retrieval;
evidence verification.
The fourth phase of non-repudiation, that of dispute arbitration, is outside the scope
this pattern.
Context
The goal of a non-repudiation service is to generate, collect, maintain, make available
and verify evidence concerning a claimed event or action in order to resolve disputes
about the occurrence or non occurrence of the event or action.
Non-repudiation services establish evidence; evidence establishes accountability
regarding a particular event or action. The entity responsible for the action, or
associated with the event, with regard to which evidence is generated, is known as the
evidence subject.
Non-repudiation mechanisms provide protocols for the exchange of non-repudiation
tokens specific to each non-repudiation service.
Non-repudiation tokens consist of secure envelopes and/or digital signatures and,
optionally, additional data:
Secure envelopes are generated by an evidence generating authority using
symmetric cryptographic techniques.
Digital signatures are generated by an evidence generator or an evidence
generating authority using asymmetric techniques.
Non-repudiation tokens can be stored as non-repudiation information that can be used
subsequently by disputing parties or by an adjudicator to arbitrate in disputes.
Problem – delivery non-repudiation
This service needs to protect against false denial of both receiving a message and
having taken notice of the content of the message. The service may be provided by the
recipient or an authority acting on behalf of the recipient.
Forces
Department of Internal Affairs 64
Non-repudiation is always based upon a formal agreement between parties that
specifies the process, procedures, evidential records and timeframes applicable.
Depending on the non-repudiation policy in effect for a specific application, and the
legal environment within which the application operates, additional information may be
required to complete the non-repudiation information, for example:
evidence including a trusted time-stamp provided by a time-stamping authority,
evidence provided by a notary which provides assurance about data created or
the action or event performed by one or more entities.
Non-repudiation can only be provided within the context of a clearly defined security
policy for a particular application and its legal environment.
The encryption and signing mechanisms will be based upon keys that have a finite life
– after which they will degrade and become less reliable and secure, and hence
inadmissible as evidence. For example – certificates used will expire or be subject to
security problems.
Solution
The first of the following solution diagrams show delivery non-repudiation with the Web
service consumer as the sender and the Web service provider as the recipient. The
second solution diagram show delivery non-repudiation with the Web service provider
as the sender and the Web service consumer as the recipient. showing non-
repudiation operating in either direction.
Department of Internal Affairs 65
Delivery non-repudiation of service request
The requirement is to protect the service consumer against false denial by service
provider of both receiving a response message and having taken notice of the content
of the message sent.
Message &
Digital Signature
Verify Signature
Timestamp
Persistent
Storage
Immediate and delayed
Non-repudiation
Processing
CipherText
Recipients
Public Key
Encrypt Decrypt
SenderRecipient
Recipients
Private Key
Request Message Request Message
Create Signature
Non-repudiation
Delivery Token
Message
Delivery Non-repudiation of service request
1. 2.
3.
3.
4.
5.6.
Web Service
Consumer
Web Service
Provider
Figure 12 - Delivery non-repudiation of service request
1. The Web service consumer creates a service request encrypting it using the
service provider’s public key.
2. The Web service provider decrypts the service request. This can only be done by
the owner of the matching private key.
3. A non-repudiation of delivery token is created by the service provider and signed
using their private key.
4. The non-repudiation of delivery token provided as a response to the consumer.
(Requires an assured delivery communication mechanism).
5. The service consumer verifies the signature using the service provider’s public
key.
6. The service consumer retains the whole message including the signature.
Department of Internal Affairs 66
Delivery non-repudiation of service response
The above example illustrates delivery non-repudiation of service request. The reverse
of this is delivery non-repudiation of a service response. Here the requirements and
actions are reversed. The requirement is to protect the service provider rather than the
service consumer against false denial by service consumer of the both receiving a
response message and having taken notice of the content of the message sent.
Service response non-repudiation is simply achieved by making the ―Sender‖ the
service provider and making the ―Recipient‖ the service consumer.
Message &
Digital Signature
Verify Signature
Timestamp
Persistent
Storage
Immediate and delayed
Non-repudiation
Processing
CipherText
Recipients
Public Key
Encrypt Decrypt
SenderRecipient
Recipients
Private Key
Response Message Response Message
Create Signature
Non-repudiation
Delivery Token
Message
Delivery Non-repudiation of service response
1. 2.
3.
3.
4.
5.6.
Web Service
Provider
Web Service
Consumer
Figure 13 - Delivery non-repudiation of service response
1. The Web service provider creates a service request encrypting it using the
service consumer’s public key.
2. The Web service consumer decrypts the service request. This can only be done
by the owner of the matching private key.
3. A non-repudiation of delivery token is created by the service consumer and
signed using their private key.
4. The non-repudiation of delivery token provided as a response to the service
provider. (Requires an assured delivery communication mechanism).
5. The service provider verifies the signature using the service consumer’s public
key.
6. The service provider retains the whole message including the signature.
Department of Internal Affairs 67
Security factors and risks
Evidence is represented by non-repudiation tokens consisting of either secure
envelopes or digital signatures. Both are based on cryptographic check values
generated by either symmetric or asymmetric cryptographic techniques, respectively.
Using certificate-based signatures, the non-repudiation token consists basically of the
signed message (which consists of the message and the signature) and its public key
certificate(s). If the public key certificate is not provided with the digital signature, it has
to be available to the appropriate parties.
Depending on the basic mechanism used for generating non-repudiation tokens, and
independent of the non-repudiation service supported by the non-repudiation
mechanisms, the following requirements hold for the entities involved in a non-
repudiation exchange.
The entities of a non-repudiation exchange shall trust the same trusted third Party
(TTP), which may be composed of several independent TTPs bound by non-
repudiation agreements.
The signature key belonging to an entity must be kept secret by that entity.
The digital signature mechanism used shall satisfy the security requirements
specified by the policy.
Prior to the generation of evidence, the evidence generator must know which
non-repudiation policies the evidence shall be generated in accordance with, what type
of evidence is to be generated, and which mechanisms are to be used to verify the
evidence.
The mechanisms for generating or verifying evidence must be available to the
entities of the particular non-repudiation exchange, or a trusted authority must be
available to provide the mechanisms.
The evidence generator and verifier may have access to a trusted time stamping
or notary facility.
Standards
ISO 13888-1
Department of Internal Affairs 68
C.9 Secure Context Centralisation
Context
WS-Security provides mechanisms for securing messages using asymmetric keys.
Often interactions between a Web service provider and a Web service consumer will
result in multiple messages being exchanged. While each message could be secured
as specified by WS-Security, use of asymmetric keys is computationally intensive. It is
more efficient to establish some form of session context, which the Web service and
consumer share, and use that context to reduce the burden with respect to securing
each message exchanged.
WS-Secure Conversation
WS-SecureConversation defines a Security Context Token to efficiently exchange a
security context that can be shared between the service consumer and service
provider to establish an asymmetric encryption session and thereby reduce the
security processing burden for each message exchanged.
Security Context Tokens
A Security Context Token is a type of security token that represents a security
context that is shared by the two communicating parties; the Web service and the
consumer of that Web service.
The security context is identified by a URI and typically contains keys that are
used as the basis for providing integrity and/or confidentiality protection for messages
transmitted between the two parties.
A security context may well contain no identity information.
A security context provides a way to establish session based security, rather than
using new keys for every message.
The Web service consumer and the Web service provider refer to the Security
Context Token by its identifier when they secure messages they exchange. They will
only use this Security Context Token (and the key material associated with it) until it
expires. If they wish to continue exchanging messages they will establish a new
Security Context Token.
Issuing Security Context Tokens
WS-SecureConversation defines a binding for WS-Trust specifically for issuing
Security Context Tokens.
Department of Internal Affairs 69
Derived Key Tokens
The WS-SecureConversation specification defines another token type, the Derived Key
Token, to deal with this issue. Keys are derived from the original secret and the derived
keys are then used to secure messages. WS-SecureConversation provides for
derivation of a pair of keys, one key for signing and one for encrypting. The
specification provides many different mechanisms for deriving keys. Using a common
secret, both parties may define different key derivations to use, providing four keys so
that two parties can sign and encrypt using separate keys.
Establishing a security context establishes a shared secret. A Security Context Token
implies or contains a shared secret. The shared secret may be used for signing and/or
encrypting messages, but it is recommended that derived keys be used for signing and
encrypting messages associated with a security context.
In order to keep the keys fresh (prevent providing too much data for analysis),
subsequent derivations may be used.
It is considered bad practice to sign and encrypt data using the same key, as certain
attacks are more likely to succeed in this case. Signing or encrypting multiple
messages with the same key is also considered bad practice.
Processing Security Context Tokens to establish a secure conversation
WS-SecureConversation provides a standard for exchanging a shared secret in a
security context token, the processes for amending, renewing and cancelling a security
context token. WS-SecureConversation defines mechanisms and data to exchange to
support generation of derived conversation keys. WS-Trust is used to exchange the
security context and supporting artefacts.
Initially the security context is established through encrypted exchanges using the
recipient's and optionally the sender's X509 certificate.
Once the security context token is available to the parties the shared secret is used
with key derivation mechanisms to create session keys that are used for encrypting
and signing the message exchanges for the life of the security context.
Department of Internal Affairs 70
Establishing a secure conversation security context
There are three ways of establishing a security context among the parties of a secure
conversation. These three options are the basis for secure conversation operation and
process. All of theses options are based upon the use of WS-Trust.
Security context token created by a security token service.
Security context token created by one of the communicating parties and
propagated with a message.
Security context token created through negotiation.
a) Security context token created by a security token service.
The context initiator asks a security token service to create a new security context
token. The security context token is accessed and distributed to the parties by the
Security Token Service through communications using WS-Trust messages. Once the
security context is established by the sender and recipient the secure conversation can
be established using symmetric keys derived from the shared secret in the security
context token.
6. Operate Secure Conversation
5b. Derive Session
Keys and operate
conversation
Request / Response
Service
Consumer Service
Secure Conversation using Security Token Service
Security
Token Service
4. Validate and cache Security
Context Token checking issued
by a trusted STS and not
tampered with
2. Issue Security
Context Token
Symmetric Key Cryptography
PKI
Cryptography
5a. Derive Session
Keys and operate
conversation
1. Request Security Context Token
and shared secret from STS Service Provider
3. Communicate Security Context Token
(Extended Brokered Authentication)
Figure 14 - Secure conversation using Security Token Service
Department of Internal Affairs 71
b) Security context token created by one of the communicating parties
and propagated with a message.
The initiator of the security context creates a security context token and sends it to the
other parties using WS-Trust messages. The initiator must be trusted by the other
parties. Once the security context is established by the recipient and the service the
secure conversation can be established using symmetric keys derived from the shared
secret in the security context token.
In this model the security context initiator must be trusted by the other parties. The
security context initiator may be the service consumer or service provider. In the
diagram below the service consumer makes a business service request to the service
provider who then initiates the security context. Equally valid is the scenario where the
service requestor is the initiator of the security context. A diagram for this may be
added.
6. Operate Secure Conversation
5b. Derive Session
Keys and operate
conversation
Request / Response
Service
Consumer Service
Secure Conversation using security context propagation
3. Security Token Context
4. Access shared secret
Symmetric Key Cryptography
PKI
Cryptography
5a. Derive Session
Keys and operate
conversation1. Request Service
2. Issue Security
Token Context and
establish shared secret
Service Provider
Shared Secret
Figure 15 - Secure conversation using security context propagation
Department of Internal Affairs 72
c) Security context token created through negotiation.
If there is a need to negotiate or exchange data to establish a security context, the
initiating party can request a security context token from a service provider optionally
sending authentication data. The service provider will then decide whether to issue a
token. Once the security context is established by the parties, the secure conversation
can be established using symmetric keys derived from the shared secret in the security
context token.
7. Operate Secure Conversation
6b. Derive Session
Keys and operate
conversationRequest / Response
Service
Consumer Service
Secure Conversation created through negotiation
4. Security Token Context
5. Access shared secret
Symmetric Key Cryptography
PKI
Cryptography
6a. Derive Session
Keys and operate
conversation
2. Challenge / Response Exchange
3. Issue Security
Token Context and
establish shared secret
Service Provider
Shared Secret
1. Request Service
Figure 16 - Secure conversation created through negotiation
Department of Internal Affairs 73