Transcript WS-security part 2

Last week…

We b Se rvice s
XM L-fam ily
Web Services
&
Security
18-1-2006 - v22

SOAP

Securing Web Services with WS-Security
By Jothy Rosenberg, David L. Remy
Sams Publishing, 2004
ISBN : 0-672-32651-5
We b Se rvice
Se curity fram e w ork
XML-family
XML-Encryption
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
Example Enc & Sig 1:
Protecting Integrity of <EncryptedData>(1/2)
EncryptedData for SSNo.
Ciphered SSNo.
Key (1) info belonging to
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 & recipient
AND 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)
The original Order
<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>
Example Enc & Sig 2:
Encryption follows Signing (2/3)
The Order, signed by David Remy
<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>
Example Enc & Sig 2:
Encryption follows Signing (3/3)
The signed order,
<Customer> is element Encrypted
<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>
EfS: however...
++ Signature, w/t
sensitive data,
invisible
++ Clear order of
processing
-- Integrity of
EncryptedData isn’t
guaranteed
In conclusion
Order of processing SfE
Security 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 Policy
Consider multi-layered approach SfEfS
Summary
XML-family
SAML
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)
Trusted Third Party TTP
Subject
Identity
(indiv./entity)
Refer
Credentials
Establishing and using Identity:
using Identity (2/2)
Portable Assertion
Trusted Third Party
TTP
Assertion:
“Presenting Credentials when
Subject initiates action”
Portable Assertion:
“Presenting Credentials when
Subject initiates action in other
Trust Domain”
Authentication: Subject is
who she claims to be.
Subject
Verify: Credentials are legitimately in
possession of Subject
Identity
Credentials
Authorization: Subject is
allowed to perform action.
Verify: Action is allowed by Credentials
(rights have been established under control
Refer
of authority responsible for action)
Trust domain NL
Trust domain HU
Problem
Solution: open federated
identity model
Federated Identity:
Credentials:
“Who is this subject”
Assertion Statement:
“I vouch that this is van Gogh”
TravelAgency.com
Credentials
Trust Domain 1
Subject
Auth. & make travel order
Book flight
ChosenAirline.com
Trust Domain 2
SAML:
1. Communicates Assertions:
• Deferred Identity Decisions
2. SAML Fundaments:
• Assertions: XML Schema
• Protocols: XML Schema for
Request/response pairs
• Bindings: Ass.s on transport &
messaging standards (currently:
SOAP@HTTP(s) )
ChosenHotels.com
ChosenRentals.com
Trust Domain 4
Trust Domain 3
Summary
Where are we?

XM L-fam ily
We b Se rvice s
Web Services
&
Security
18-1-2006 - v22

SOAP

Securing Web Services with WS-Security
By Jothy Rosenberg, David L. Remy
Sams Publishing, 2004
ISBN : 0-672-32651-5
We b Se rvice
Se curity fram e w ork
SOAP
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 InterORB 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 Simple
it doesn't deal with Objects
It's got more to do with transport than
Access
from version 1.1: SOAP is no longer an
acronym
sometimes: Service-Oriented Architecture
(or Application) Protocol
Characteristics
SOAP = XML derivative
Hence character oriented
Hence easier debugging (meta-data
describing what is being passed)
Hence firewall friendly
Treat XML messages as service request
Separation between infrastructure &
application processing of messages
Supported transport
protocols
Number of Transport protocols = 1
Technically, 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 envelope
Manage the package
Extensibility is located here
SOAP Security (extensions) lives here
SOAP Body
Information about SOAP Content
Containts the message payload, i.e. XML
Data
Anything: full purchase order doc, RPC
inc. method & parameters
SOAP binding & encoding
 Binding Style ::
 How to bind XMLelements 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 XMLstructure
 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
WS-Security
Objective
complements) transportbased 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-intermediaryto-end
 ... new, relatively
complex, many options
 ... Very granular: part of
payload, single message
 ... Transport independent
Characteristics
As flexible as XML
Each message carries own security
strategy
Flexibility is strength AND weakness
WS-Security = SOAP security
WS-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 SOAP
Doing so, defines SOAP security header
Doing so, defines SOAP
security header
Security Tokens
XML-Encryption
XML-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
PrivKey
Kerberos 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
Username / password
<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>
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 integrity
Goal 2: To verify a security token
credential
Goal 1: To provide
message integrity
Username / password
<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>
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
Summary
Where are we?

We b Se rvice s
XM L-fam ily
Web Services
&
Security
18-1-2006 - v22

SOAP

Securing Web Services with WS-Security
By Jothy Rosenberg, David L. Remy
Sams Publishing, 2004
ISBN : 0-672-32651-5
We b Se rvice
Se curity fram e w ork
Web Service Security
framework
Foundation: WS-Security
XML-Signature
XML-Encryption
SAML-Assertions
Binds to SOAP:
secure interaction
Secure XML leftovers
Secure XML leftovers
XKMS
XACML
XrML
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.
Web Service Security
framework
Landscape of web serv ices
related WS* standards on top
Web Service
Security framework
19-1-2006 - v5
Foundation: WS-Security
related WS* standards on
top
WS-Policy framework
WS-Trust
WS-Privacy
WS-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, WSSecureConversation)
There are numerous ways of integrating different
trust domains (or realms) when utilizing the WSSecurity, 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.
Web Service Security
framework
Landscape of web serv ices
related WS* standards on top
Web Service
Security framework
19-1-2006 - v5
Foundation: WS-Security
Landscape of web
services
WS-Security landscape
XML-landscape
WS*-landscape
Cliff hanger
Wha t do you need to k now to pa ss
your exa m
Principles
Unde rs tanding XM L-Signature &
XM L-Encryption & SOAP
Understand purpose of major <element>s
Reading, not writing
Basic understanding of XML grammar
Cliff hanger
19-1-2006 - v3
Principles
Understand its purpose
Unde rs tanding WS-Se curity
Know its compounding structure
Recognise dif f erences between v arious
usage scenarios
Invitation
Enjoyed Web services and/or Security?
… doing your master’s thesis
Consider applying with TNO …