Last week…

Last week…

Web Services XML-family

SOAP Web Service Security framework

Web Services&

Security18-1-2006 - v22

By Jothy Rosenberg, David L. Remy Sams Publishing, 2004 ISBN : 0-672-32651-5

Securing Web Services with WS-Security

XML-family

XML-Encryption

Objective

XML-Encryption structure

Resulting Schema shorthand

<EncryptedData Id? Type? MimeType? Encoding?><EncryptionMethod/>?<ds:KeyInfo>

<EncryptedKey>?<AgreementMethod>?<ds:KeyName>?<ds:RetrievalMethod>?<ds:*>?

</ds:KeyInfo>?<CipherData>

<CipherValue>? <CipherReference URI?>?

</CipherData><EncryptionProperties>?

</EncryptedData>

Web service security:Part 2

Combining XML-Encryption with XML-Signature

EncryptedData for SSNo.

Key (1) info belonging to Ciphered SSNo.

Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(1/2)

Ciphered SSNo.

EncryptedData for Key

Encrypted Key to decrypt Ciphered SSNo.

Key (2) info belonging to Encrypted Key

Signed info refers to Encrypted Data for SSNo.

Digest of EncryptedData for SSNo.

Signature of SignedInfo

Key (3) info to verify Signature

Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(2/2)

Reasonable Statement

Iff:Confident keys are associated with sender & recipientAND private keys are not compromised

Then:“This document was prepared by David Remy and can only be read by Jothy Rosenberg”

SfE: however...

<Signature> & <EncryptedData> are detached

<Signature> can be removed without being noticed

<Signature> can even be replaced: "Signed by David Copperfield"

Need Policy: If encrypted, then also signed

BTW: what's the order of processing ??

Example Enc & Sig 2: Encryption follows Signing (1/3)

<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <FirstName>Fred</FirstName> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CreditCardType>VISA</CreditCardType> <CreditCardNumber>43343456343566</CreditCardNumber> <CreditCardExpiration>10/08</CreditCardExpiration> </CreditCard> </Customer></Order>

The original Order


<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <Name . . . /> <CreditCard . . . /> <Signature> <SignedInfo> <CanonicalizationMethod Algorigthm=". . ." /> <SignatureMethod Algorithm=". . ." /> <Reference URI="#customer"> <Transform Algorithm=".../#envelopedSignature" /> <DigestMethod Algorithm=". . ." /> <DigestValue>. . .</DigestValue> </Reference> </SignedInfo> <SignatureValue>. . . </SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>O=MyCompany,OU=Engineering,CN=David Remy</X509SubjectName> </X509Data> </KeyInfo> </Signature> </Customer></Order>

The Order, signed by David Remy


<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <EncryptedData id="encryptedData1" Type="Element"> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . . </CipherValue> </CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . .</CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject>O=HisCompany,OU=Technology,CN=Jothy Rosenberg</X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData></Order>

The signed order, <Customer> is element Encrypted

EfS: however...

++ Signature, w/t sensitive data, invisible

++ Clear order of processing

-- Integrity of EncryptedData isn’t guaranteed

In conclusion

Order of processing SfESecurity Model: SfE or EfS

Order of processing SfE

Problem: What to do 1st, Decrypt or Validate Signature

Solution: additional 'Decrypt Transform' element for XML-Signature

Security Model: SfE or EfS

Depends on context, the specific situation

Specify a PolicyConsider multi-layered approach

SfEfS

Summary

XML-family

Identity

Significance of Identity

Questions focus around Identity:

Who is accessing my network / information?

Who is this request from?

Who sais this information is correct?

Who sent me this confidential information?

How do I know it is really the sender?

...

Establishing and using Identity: establishing Identity (1/2)

Subject(indiv./entity)

Trusted Third Party TTP

Credentials

Refer

Identity

Trust domain HUTrust domain NL

Establishing and using Identity: using Identity (2/2)

Trusted Third Party TTP

Refer

IdentitySubject Credentials

Assertion:“Presenting Credentials when

Subject initiates action”

Authentication: Subject is who she claims to be.

Verify: Credentials are legitimately in possession of Subject

Authorization: Subject is allowed to perform action.

Verify: Action is allowed by Credentials (rights have been established under control of authority responsible for action)

Portable AssertionPortable Assertion:

“Presenting Credentials when Subject initiates action in other

Trust Domain”

Problem

Solution: open federated identity model

Order car

Book flight

Federated Identity:

SubjectTravelAgency.com

Trust Domain 1Trust Domain 1

ChosenAirline.comTrust Domain 2Trust Domain 2

ChosenRentals.comTrust Domain 3Trust Domain 3

ChosenHotels.comTrust Domain 4Trust Domain 4

Auth. & make travel order

Credentials

Book flight

SAML: 1. Communicates Assertions:

• Deferred Identity Decisions2. SAML Fundaments:

• Assertions: XML Schema• Protocols: XML Schema for

Request/response pairs• Bindings: Ass.s on transport &

messaging standards (currently: SOAP@HTTP(s) )

Assertion Statement:“I vouch that this is van Gogh”

Credentials:“Who is this subject”

Summary

Where are we?



Web Services&

Security18-1-2006 - v22



Objective & Characteristics

Transport of XML data

Where XML defines the content of a message ...

SOAP defines how that data moves from A to B

Via a number of standard transport protocols, but ...

Extensible to future needs (protocols & standards, functionality)

SOAP is for web services...

.... what Internet Inter-ORB Protocol (IIOP) is for CORBA ....

... and RMI is for Java Allows Sender &

Receiver to support common transport protocol

Simple Object Access Protocol

It isn't Simpleit doesn't deal with ObjectsIt's got more to do with transport

than Accessfrom version 1.1: SOAP is no longer

an acronymsometimes: Service-Oriented

Architecture (or Application) Protocol

Characteristics

SOAP = XML derivativeHence character orientedHence easier debugging (meta-data

describing what is being passed)Hence firewall friendlyTreat XML messages as service

requestSeparation between infrastructure &

application processing of messages

Supported transport protocols

Number of Transport protocols = 1Technically, spec supports expansion

to others (UDP, SMTP, JMS, etc.)Spec Formal binding to HTTP

Structure

Provide transport envelope

Envelope = container to hold XML Data

Uniform container, then be carried by variety of transports

Applications refer to content

Transport refers to envelope

SOAP Header

Information about SOAP envelopeManage the packageExtensibility is located hereSOAP Security (extensions) lives

here

SOAP Body

Information about SOAP ContentContaints the message payload, i.e.

XML DataAnything: full purchase order doc,

RPC inc. method & parameters

SOAP binding & encoding

Binding Style :: How to bind XML-

elements on physical remote methods & parameters

Binding style: RPC versus Document

RPC/Encoded: remote invocated procedures, synchronous, design-time binding

Encoding Type :: How to encode

original objects: Serialization of original object onto hierarchical XML-structure

Encoding type: SOAP encoded versus Literal

Document/Literal: document processing, asynchronous, run-time binding

SOAP processing

SOAP Processors are part of application servers

SOAP runtime system acts upon Headers & Bodies

SOAP intermediaries act only upon Headers

Security: authenticate identities, encrypt or decrypt, validate signatures & call-out TTP authorities, ...

WS-Security

Objective

contrasts (& complements) transport-based security

Secure pipe between 2 directly connected endpoints

Endpoints usually Application Server

Secure IN the pipe, not outside

What about, for instance, logging?

Comparing Transport vs Message based security

Comparing Transport vs Message based security

Transport based: ... Point-to-point ... Mature,

straightforward impl. ... Not granular: entire

payload, entire session

... transport dependent

Message based: ... End-to-

intermediary-to-end ... new, relatively

complex, many options

... Very granular: part of payload, single message

... Transport independent

Characteristics

As flexible as XMLEach message carries own security

strategyFlexibility is strength AND weaknessWS-Security = SOAP securityWS-Security = part of Web Service

Security framework

WS-Security structure

WS-Security: What does it do?

Takes XML Security (XML-Enc & XML-Sig)

Links that with tokens (X509, Kerberos, SAML)

Binds that to SOAPDoing so, defines SOAP security

header

Doing so, defines SOAP security header

Security TokensXML-EncryptionXML-Signature

3 Building blocks

(1/3) Security Tokens

(2/3) XML-Encryption

(3/3) XML-Signature

(1/3) Security Tokens

Information used for authentication & authorization (i.e. username / password, X.509 Certificate, ...)

<UsernameToken><BinaryToken><XML tokens>

<UsernameToken>

<Username><Password> in

clear (over SSL) -> Don't!

Use PasswordType = PasswordDigest instead:

...Time stamp

... Nonce... Password Hash... Requires clear-

text password on both sides

<BinaryToken>

Support few classes of binary credentials

X.509 certificates... needs Signature proving

possession PrivKeyKerberos tickets

<XML tokens>

n XML token = n wrapping top-elements

SAML Assertion: <saml:Assertion>eXtensible Rights Markup Language

(XrML)XML Common Biometric Format

(XCBF)... and new tokens will be developed

WS-Security: SecurityTokens in SOAP

<Envelope> <Header> <wsse:Security> SecurityToken

<ds:Signature> <ds:SignedInfo> <ds:Reference URI=“#MsgBody”> <ds:DigestValue>…</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>…</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> ReferenceToSecurityToken </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </Header> <Body Id=MsgBody> </Body></Envelope>

Username / password

Binary token

XML Token

Tokens have different syntax, hence distinct TokenReference

Announcement

SAML Assertion: <saml:Assertion>

Goal is to confirm that:

... sender, or ... third party,

vouching for the sender,

... has proof of sender's identity

Hence: <holder-of-key> or <sender-vouches>

(2/3) XML-Encryption

Hide selective information in SOAP messages

Security header holds <Encryptedkey> element

containing <ReferenceList> pointing to specific message parts

Encrypted attachments: SOAP w/t Attachments (SwA) not yet recommendation status

Example: Wrapped Symmetrical Key XML Encryption

(3/3) XML-Signature

Goal 1: To provide message integrityGoal 2: To verify a security token

credential

Goal 1: To provide message integrity

<Envelope> <Header> <wsse:Security> SecurityToken

<ds:Signature> <ds:SignedInfo> <ds:Reference URI=“#MsgBody”> <ds:DigestValue>…</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>…</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> ReferenceToSecurityToken </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </Header> <Body Id=MsgBody> </Body></Envelope>

Username / password

Binary token

XML Token

Tokens have different syntax, hence distinct TokenReference

Announcement

Goal 2: To verify a security token credential

Reminder: SignatureValue is calulated over <SignedInfo>-block

... containing <reference> and ...

...Digest of reference. Problem: that is always

<SecurityTokenReference> rather than token itself

WS-Security therefore will follow token reference ("STR Dereference Transform" strategy)

Summary

Where are we?



Web Services&

Security18-1-2006 - v22



Web Service Security framework

Foundation: WS-Security

XML-SignatureXML-EncryptionSAML-AssertionsBinds to SOAP:

secure interactionSecure XML

leftovers

Secure XML leftovers

XKMSXACMLXrML

XKMS

Used for distributing and registering public keys:

Support the registration of a key pair by a key pair holder;

Delegates the processing of Key Information associated with an XML signature, XML encryption, or other public key.

Can be used as alternate for SAML when participants don't have single trust agreement established.

XACML

The XACML (extensible access control markup language) specification consists of two related vocabularies: one for access control and one that defines a vocabulary for request and response exchanges. Through these languages, the creation of fine-grained security policies is made possible.

XrML

Extensible Rights Markup Language is a grammar for expressing rights and conditions associated with digital content, services, or any digital resource.

Can be used as WS-Security token.



related WS* standards on topLandscape of web services


19-1-2006 - v5

related WS* standards on top

WS-Policy framework

WS-TrustWS-PrivacyWS-Federation

framework

WS-Policy framework

Where WS-Security implements security,

the WS-Policy framework is used to describe what has been implemented:

... What security token is required?

... Encryption is required.

... What part of the message must be encrypted? Signed? Whole body or a part?

... numerous options to agree upon

Both for server AND client (!)

WS-Trust

This specification establishes a standard trust model used to unite existing trust models, so that the validity of exchanged security tokens can be verified. WS-Trust provides a communications process for requesting the involvement of third-party trust authorities to assist with this verification.

WS-Privacy

Organizations can use WS-Privacy to communicate their privacy policies and check to see whether requestors intend to comply to these policies. WS-Privacy works in conjunction with WS-Policy and WS-Trust.

WS-Federation framework

(WS-Federation, WS-Authorization, WS-SecureConversation)

There are numerous ways of integrating different trust domains (or realms) when utilizing the WS-Security, WS-Policy, and WS-Trust standards. The WS-Federation specification provides a series of standards and security models for achieving a federation — an environment where a level of trust has been established between disparate trust domains.



related WS* standards on topLandscape of web services


19-1-2006 - v5

Landscape of web services

XML-landscape WS*-landscape

WS-Security landscape

Cliff hanger

Understanding XML-Signature & XML-Encryption & SOAP

Understanding WS-Security

Cliff hanger19-1-2006 - v3

Principles

Understand purpose of major <element>s

Reading, not writing

Basic understanding of XML grammar

Principles

Understand its purpose

Know its compounding structure

Recognise differences between various usage scenarios

What do you need to know to pass your exam

Invitation

Enjoyed Web services and/or Security?

Consider applying with TNO …

… doing your master’s thesis

Last week…

Documents

Transcript of Last week…