government enterprise architecture for new ... - … · government enterprise architecture for new...

- 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


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.

http://creativecommons.org/licenses/by/3.0/nz/

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=6485


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


Group

Includes Government Enterprise

Architecture Group (GEAG) required

changes.

1.0 18/04/2013 New Zealand Secure


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


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


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.


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


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.


Intentionally blank


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


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


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.


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.

http://hitachi-id.com/concepts/public_key.html

http://hitachi-id.com/concepts/public_key_infrastructure.html



http://hitachi-id.com/concepts/ssl.html

http://hitachi-id.com/concepts/https.html


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).


http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

http://www.ietf.org/rfc/rfc2616


http://www.w3.org/TR/2006/REC-ws-addr-core-20060509

http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/


http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/


http://www.w3.org/TR/2006/NOTE-soap11-ror-httpbinding-20060321/

http://www.w3.org/TR/soap12-mtom/

http://www.w3.org/TR/xop10/

http://www.w3.org/Submission/2006/SUBM-soap11mtom10-20060405/

http://www.w3.org/TR/2006/REC-xml-20060816/

http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

http://www.apps.ietf.org/rfc/rfc3986.html

http://www.w3.org/TR/2006/REC-xml-names-20060816/

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/


http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm

http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm

http://uddi.org/schema/uddi_v2.xsd

http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm#_Toc25130769




http://wp.netscape.com/eng/ssl3/draft302.txt




b) WS-I BasicProfile (BP) 2.0


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


http://www.w3.org/TR/2007/REC-soap12-part1-20070427/

http://www.w3.org/TR/2007/REC-soap12-part2-20070427/



http://www.w3.org/TR/2006/REC-ws-addr-core-20060509





http://www.w3.org/TR/soap12-mtom/

http://www.w3.org/TR/xop10/


http://www.w3.org/TR/2006/REC-xml-20060816/

http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

http://www.apps.ietf.org/rfc/rfc3986.html

http://www.w3.org/TR/2006/REC-xml-names-20060816/



http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://www.w3.org/Submission/wsdl11soap12/

http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm

http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm

http://uddi.org/schema/uddi_v2.xsd





http://wp.netscape.com/eng/ssl3/draft302.txt



http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html


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.

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html


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


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.

http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx

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/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

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html


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

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html

http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.html

http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.html


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.


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


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.


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).


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.


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.


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.


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.


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.


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.


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.


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.


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.



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:


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 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.


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


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.




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 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


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.


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


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



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 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.


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.


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


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


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.

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.

http://msdn.microsoft.com/library/en-us/dnglobspec/html/WS-trust.pdf


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.

http://www.oasis-open.org/specs/index.php#samlv1.1


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


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.


However, it does discuss many of the issues that are most commonly encountered for

this pattern.


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.


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


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.


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


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.


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..


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:


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


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.



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.


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.


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.


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.


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


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


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.


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


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.


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


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.


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


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.


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.


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


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.


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


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


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.


6b. Derive Session

Keys and operate

conversationRequest / Response

Service

Consumer Service

Secure Conversation created through negotiation

4. Security Token Context

5. Access shared secret


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

government enterprise architecture for new ... - … · government enterprise architecture for new...

Documents