T-110.455 Network Application Frameworks and XML Web Service Security 06.04.2005 Sasu Tarkoma Based on slides by Pekka Nikander.

T-110.455 Network Application Frameworks and XML

Web Service Security

06.04.2005

Sasu Tarkoma

Based on slides by Pekka Nikander

Announcements

A list of papers to read for the final exam Bob Braden, Architectural Principles of the Internet,

IPAM Tutorial March 12, 2002. Jukka Ylitalo and Pekka Nikander,

A new Name Space for End-Points: Implementing secure Mobility and Multi-homing across the two versions of IP, in Proceedings of the Fifth European Wireless Conference, Mobile and Wireless Systems beyond 3G (EW2004), pp. 435-441, Barcelona, Spain, February 24-27, 2004.

Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Michael Walfish, "A Layered Naming Architecture for the Internet", ACM SIGCOMM 2004, Portland, OR, September 2004.

We will have an invited lecture on 13.04. by Jaakko Kangasharju on wireless web services. Everyone should attend!

Contents

Review Requirements Security contexts WS security standard revisited SAML Summary

Standardization Groups

XML EncryptionXML Encryption

XML SignatureXML Signature XKMSXKMS

XrMLXrML

WS-SecurityWS-Security

ProvisioningProvisioning

BiometricsBiometrics

XACMLXACMLSAMLSAML

W3C OASIS

Security Assertion Markup language

XML Common Biometric Format (XCBF)

Extensible Rights Markup Language

eXtensible Access Control Markup Language (XACML)XML Key Management

Specification

Digital Signatures

MessageDigest

MessageDigest

Message

Private key Public keyAsymmetric Key Pair

SIGN VERIFYSignature Pass/Fail

Need to know the message, digest, and algorithm (f.e.

SHA1)

XML Digital Signatures (cont.)

<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?>

(<Transforms>)? <DigestMethod></DigestMethod>

<DigestValue></DigestValue> </Reference>)+ </SignedInfo> <Signaturevalue></Signaturevalue> (<KeyInfo>)? (<Object ID?>)*</Signature>

Encryption

Public key Private keyAsymmetric Key Pair

Encrypt Decrypt

XML Encryption

<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 Services Security Requirements

Access control to Web services WS-Security, XML-Signature SAML – Issuing and validation of SAML

assertions Digital certificate validation

Content-filtering XML Filters based on data format (XSD) Filters based on content (XPath) Filters based on integrity (XML Signature)

Functional point of view

Routing

Integrity Validation

Content Checking

Authentication

Authorization

XML

ManagementConsole

Design andDeploySecuritypolicies

ID ManagementLDAPPKI

Single Sign-On

ReportingActivityAlerting

Secure loggingXML

Security Contexts in Web Services

Remember Web Services goals: Re-use existing services Combine services from several domains

Security result: Must support several security domains SOAP intermediaries Reusing security tokens from one message in

another message

Example 1: Pass subject details

Web Browser

WebsiteAppl.

ServerWeb

Service

HTTP POST SOAP

Security Context I

Security Context II

Main Point: We need security within AND between security contexts!

Example 2: SOAP Routing

SOAP HTTP SOAP SMTP

Security Context I

Security Context II

Main Point: We need XML validation, encryption, and authentication between

security contexts!

WS Security I

Web Services Security: SOAP Message Security 1.0 (Oasis Standard 2004)

End-to-End security Headers are decrypted and processed as needed

Selective processing Some parts are plain text Some are encrypted Some are signed

How does it work? SOAP header carries security information (and

other info as well)

WS Security II

Ability to send security tokens as part of a message, message integrity, and message confidentiality

Security model in terms of security tokens combined with digital signatures to protect and authenticate SOAP messages

An X.509 is an example of a signed security token endorsed by a CA.

When third party support is not available, receiver may choose to accept the claims in the token based on trust on the entity that sent the message.

Goals

Multiple security token formats Multiple trust domains Multiple signature formats Multiple encryption technologies End-to-end message content security

and not just transport-level security

Non-goals

Establishing a security context or authentication mechanism

Key derivation Advertisement and exchange of security

policy How trust is established or determined Non-repudiation

Message Protection

Integrity mechanism designed to support multiple signatures

Uses XML Signature and XML Encryption Syntax and semantics of signatures within a

<wsse:Security> element This is the security block in the SOAP header SOAP actor/role attribute is used to target header

blocks Security element includes

Security tokens Information about the use of XML Encryption &

Signature in the SOAP header/body/combination

Security Header

May be present multiple times in a SOAP message Must have different actor/role attribute values

Unrecognized extension elements or attributes should cause a fault

Receivers MAY ignore elements or extensions within the <wsse:Security> element, based on local security policy

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap=""..." xmlns:wsu="...” xmlns:wsse="..."> <soap:Header> <wsse:Security soap:mustUnderstand=”..”>..</wsse...> </soap:Header> <soap:Body> ... </soap:Body></soap:Envelope>

Security Element: enclosing information

UsernameToken block Defines how username-and-password info is enclosed in

SOAP End users: SAML Authentication Assertion or Kerberos

ticket, shared uname/pwd secret Password must be protected against eavesdroppers

(enc) and replay (timestamp/nonce) BinarySecurityToken block

Encloses binary data An X.509 certificate or a Kerberos ticket Has an identifier (Id), a value (ValueType), and an

encoding (EncodingType) XML Signature KeyInfo may point to a certificate used in

signing using a Reference to its Id. Similar for XML Encryption.

So we can sign/encrypt data with a certificate in the header.

ID References

A new global attribute: wsu:Id attribute <anyElement wsu:id=”..”>..</anyElement> Note that the SOAP processor needs to support

this wsu:id a WS-Security namespace (wssecurity-

secext-1.0.xsd) Recipients do not need to understand the full

schema of the message for processing the security elements

Two wsu:Id attributes within an XML document MUST NO have the same value

Recommended that wsu:Id is used instead of a more general transformation, especially XPath

Signatures

Does not use the Enveloped Signature Transform Due to mutability of SOAP header

Does not use the Enveloping Signature Explicitly include the elements to be

signed Allows for extensions, multiple signatures,

etc.

Canonicalization

XML Canonicalization and Exclusive XML Canonicalization

Problems XML tools change documents, e.g. duplicate

namespace declarations can be removed or created

Signature simply covers something like xx:foo, its meaning may change if xx is redefined

There are mechanisms like XPath, which consider xx=”http://example.com”; to be different from yy=”http://example.com/”

Inclusive Canonicalization

Copies all the declarations that are currently in force

Useful in the typical case of signing part or all of the SOAP body

Causes problems for signatures when the context changes (for example by intermediaries)

Exclusive Canonicalization

Tries to figure out what namespaces are actually used and just copies those

Does not look into attribute values or element content Can happen implicitly because XML processing

tools will add xsi:type if schema subtypes are used Useful when you have an XML document that

you wish to insert into another XML document Example: signed SAML assertion

Should be used with WS-Security: SOAP Message Security (recommended)

Signing Messages

Multiple signature entries MAY be added into a single SOAP Envelope within one <wsse:Security> header block

MUST be prepended to the existing content <ds:Reference> elements contained in the signature

should refer to a resource within the enclosing SOAP envelope

<wsse:SecurityTokenreference> Extensible mechanism that provides an open content

model for referencing security tokens New reference option for XML signature

STR Deference Transform Means that the output is the token referenced by the

element, not the element itself You can conveniently locate and sign security tokens

anywhere in the header

Example of a Token with signature

<wsse:SecurityTokenReference wsu:Id="Str1"> ...</wsse:SecurityTokenReference>...<ds:Signature xmlns:ds="http://...xmldsig#"> <ds:SignedInfo> <ds:Reference URI="#Str1"> <ds:Transforms> <ds:Transform Algorithm="...#STR-Transform">... </ds:Transform></ds:Transforms> <ds:DigestMethod Algorithm="http://...#sha1"/> <ds:DigestValue>...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue></ds:SignatureValue></ds:Signature>

Open content model for specifying token. It could be XML,

URI, …

We use the content here using #STR-Transform and compute the

digest

Extended example

SOAP Envelope SOAP Header

WS Security

• Security token (a certificate)

• Encryption key (passing symmetric key)

• Signature SOAP Body

Encrypted content

Overall message structure

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope> <soap:Header> <wsse:Security> <wsse:BinarySecurityToken>...</wsse:Binary...> <xenc:EncryptedKey>...</xenc:EncryptedKey> <ds:Signature> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo>...</ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body wsu:Id="body"> <xenc:EncryptedData>...</xenc:EncryptedData> </soap:Body> </soap:Envelope>

Security block

1.2.

3.

4.

1. Binary security token

<wsse:Security><wsse:BinarySecurityToken ValueType="...#X509v3" wsu:Id="X509Token" EncodingType="...#Base64Binary"> ABCDEF....</wsse:BinarySecurityToken><xenc:EncryptedKey>...</xenc:EncryptedKey><ds:Signature>...</ds:Signature></wsse:Security>

2. Passing encryption key

<xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm="...#rsa-1_5"/> <ds:KeyInfo> <wsse:KeyIdentifier EncodingType="...#Base64Binary" ValueType="...#X509v3"> ABCDEF.... </wsse:KeyIdentifier> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#enc1"> </xenc:ReferenceList> </xenc:EncryptedKey>

We are using another certificate for asymmetric

crypto.

Encrypted symmetric key

Reference to cipher data

3. Actual signature<ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod algorithm="http://...-exc-c14n#"/> <ds:SignatureMethod algorithm="http://...#rsa-sha1"/> <ds:Reference URI="#T0">...</ds:Reference> <ds:Reference URI="#body">...</ds:Reference> …. </ds:SignedInfo> <ds:SignatureValue> ..... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo></ds:Signature>

Exclusive canonicalization

References & digests to data

Reference to certificate.

<ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://...-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://...#rsa-sha1"/> <ds:Reference URI="#T0"> <ds:Transforms> <ds:Transform Algorithm="http://...exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://...#sha1"/> <ds:DigestValue>...</ds:DigestValue> </ds:Reference> <ds:Reference URI="#body"> <ds:Transforms> <ds:Transform Algorithm="http://...exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://...#sha1"/> <ds:DigestValue>...</ds:DigestValue> </ds:Reference> </ds:SignedInfo>

3. SignedInfo in more detail

4. Actual message body

<soap:Body wsu:Id="body"> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" wsu:Id="enc1"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <xenc:CipherData> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData></soap:Body></soap:Envelope>

Error Handling

SOAP Faults are used to indicate faults Error scenarios

Security token type unsupported Note: WS-Policy may be used to convey what security

tokens can be understood by different parties Fault code: InvalidSecurity (if contents of the header block

cannot be processed) Invalid security token

For example: security token corrupted or has invalid signature

Fault code: InvalidSecurityToken Security token cannot be authenticated

For example: given certificate cannot be validated Fault code: FailedAuthentication

Security token unavailable For example: a certificate was referenced that could not be

located Fault code: wsse:SecurityTokenUnavailable

SAML

SAML (Security Assertion Markup Language) A XML-based framework (schemas) for the

exchange of authentication and authorization information

A standard message exchange protocol How you ask and receive information

Mainly for integration, up to relying parties to decide to what authentication authority to trust

Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources Authentication statements merely describe acts

of authentication that happened previously Specified by OASIS

SAML in a nutshell

XML-based framework for exchanging security information XML-encoded security assertions XML-encoded request/response protocol Rules on using assertions with standard

transport and messaging frameworks

SAML & WS-Security allow a SOAP message to include information about the end-user’s authentication status

SAML Motivation: Portable Trust

UserUser

ServiceService

UserUser

ServiceService

Domain A Domain B

Authenticationserver A

Authenticationserver A

Authenticationserver B

Authenticationserver B

Using services in B from A?Authentication at B?

Not acceptable!

UserUser

ServiceService

UserUser

ServiceService

Domain A Domain B

Authenticationserver A

Authenticationserver A

Authenticationserver B

Authenticationserver B

Authenticationserver C

Authenticationserver C

Timed updates

Timed updates

SAML assertions

An assertion is a declaration of fact about a subject, e.g. a user According to some assertion issues

SAML has three kinds, all related to security: Authentication Attribute Authorization decision

You can extend SAML to make you own kinds of assertions

Assertions can be digitally signed

All assertions have some common information

Issuer and issuance timestamp Assertion ID Subject

Name plus the security domain Optional subject information, e.g. public key

”Conditions” under which assertion is valid SAML clients must reject assertions containing

unsupported conditions Special kind of condition: assertion validity period

Additional ”advice” E.g. to explain how the assertion was made

Authentication assertion

An issuing authority asserts that: Subject S was authenticated by means M at time T

Caution: actually checking or revoking of credentials is not in the scope of SAML! Password exchange Challenge-response Etc.

It merely lets you link back to acts of authentication that took place previously

Example authentication assertion<saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="127.0.0.1.1234567" Issuer="Example Corp" IssueInstant="2005-04-04T09:00:00Z"> <saml:Conditions NotBefore="2005-04-04T09:00:00Z" NotAfter=""2005-04-04T09:05:00Z"/> <saml:AuthenticationStatement AuthenticationMethod="password" AuthenticationInstant="2005-04-04T09:01:00Z"> <saml:Subject> <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe"/> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

Attribute assertion

An issuing authority asserts that: subject S is associated with attributes A,B,.. with values ”a”,”b”,…

Typically this would be gotten from an LDAP repository ”john.doe” in ”example.com” is associated with attribute ”Department” with value ”Human Resources”

Example attribute assertion<saml:Assertion ...> <saml: Conditions .../> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe" /> </saml:Subject> <saml:Attribute AttributeName="PaidStatus" AttributeNameSpace="http://example.com"> <saml:AttributeValue> PaidUp </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

Authorization decision assertion

An issuing authority decides whether to grant the request by subject S for access type A to resource R given evidence E

The subject could be a human or a program

The resource could be a web page or a web service, for example

Example authorization decision assertion

<saml:Assertion ...> <saml:Conditions .../> <saml:AuthorizationStatement Decision="Permit" Resource="http://example.com/res123"> <saml:Subject> <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe" /> </saml:Subject> </saml:AuthorizationStatement> </saml:Assertion>

Assertion type Description

Authentication Assertion

Asserts that subject S was authenticated by means M at time T

Attribute Assertion

Asserts that subject S is associated with attributes A1, A2,… with values V1,V2,...

Authorization Decision Assertion

Should the request to subject S for access type A be granted to resource R given evidence E

A username token in WS-Security SOAP Header

<SOAP:Envelope xmlns:SOAP="..."> <SOAP:Header> <wsse:Security xmlns:wsse="http://...secext"> <wsse:UsernameToken> <wsse:UserName>abc</wsse:UserName> <wsse:Password Type="wsse:PasswordDigest"> xyzabc </wsse:Password> <wsse:Nonce> ap2oep3oaeap1 </wsse:Nonce> </wsse:UsernameToken> ... </wsse:Security> </SOAP:Header> <SOAP:Body Id="body"> ... </SOAP:Body> </SOAP:Envelope>

A Binary X.509 Certificate in WS-Security SOAP header

<wsse:Security xmlns:wsse="http://...secext"> <wsse:BinarySecurityToken Id="X509Token" xmlns:wsse="...secext" ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> ABCDEF.. </wsse:BinarySecurityToken> <ds:Signature xmlns:ds="...xmldsig#"> <ds:SignedInfo>...</ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </Signature> ...</wsse:Security>

A SAML Assertion in WS-Security SOAP Header <wsse:Security xmlns:wsse="http://...secext">

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" Minorversion="0" AssertionID="SecurityToken-123" Issuer="example.com" IssueInstant="2005-04-04T09:00:00Z"> ... </saml:Assertion> <ds:Signature xmlns:ds="...xmldsig#"> <ds:SignedInfo>...</ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference>

<saml:AssertionIDReference> SecurityToken-123</saml:AssertionIDReference>

</wsse:SecurityTokenReference> </ds:KeyInfo> </Signature> ...</wsse:Security>

SAML does not allow the use of the ID attribute with assertion elements, hence AssertionIDReference is

used

SAML and XACML

PEPPolicy Enforcement Point

PEPPolicy Enforcement Point

Web ServiceWeb Service

PDPPolicy Decision Point

PDPPolicy Decision Point

PRPPolicy Retrieval Point

PRPPolicy Retrieval Point

PIPPolicy Information Point

PIPPolicy Information Point

Policy Store(XACML)

Policy Store(XACML)

PAPPolicy Admin. Point

PAPPolicy Admin. Point

WS request (SOAP)

WS request

SAML Authrz. decision query

Reply

XACML Policy request Policy (XACML)

Info request

Attribute assertion

Rules are combined: subjects, resources, and attributes.

Exported into XACML.

PDP queries attributes from PIP (time of day,

value, etc.). PIP returns an attribute assertion.

Once the PDP has all the relevant

information, it evaluates rules and

returns a SAML authoriz. Assertion

Once the SAML authoriz. Has ben made it may be included into the SOAP message and

used by the target WS.

SOAP msg isIntercepted. SAML query is formed, results determine

access. Identity info taken from request. There may be multiple

PEPs.

Implementations

Trust Services Integration Kit (TSIK), Verisign Java API for creating trusted services, includes a SAML API http://www.xmltrustcenter.org/developer/verisign/tsik/

index.htm Apache XML-Security, Apache Software Foundation

XML Digital Signature and XML Encryption (Java, C++) http://xml.apache.org/security/

Web Services Enhancements 2.0, Microsoft .NET implementation of various WS Security specs. http://msdn.microsoft.com/webservices/building/wse/

Microsoft Passport, Microsoft Single sign-on support

XML Security Suite, IBM XML Digital Signature, XML Encryption and XML Access

Control Language (Java) http://www.alphaworks.ibm.com/tech/xmlsecuritysuite

SunONE Identity Server, Sun Microsystems Supports Liberty’s federated identity and SAML

Web Services Enhancements 2.0

Implements many of the rules of the WS-* specifications

Works with HTTP and SOAP (SoapExtensions)

Supported specifications WS-Security, WS-SecurityPolicy, WS-

SecureConversation, WS-Trust, WS-Referral, WS-Addressing, WS-Policy, WS-Attachments

Supports signing/encrypting message elements and policies

More information and downloads

Lecture Summary

Security contexts Security needed within and between contexts XML validation, encryption, and authentication

needed between security contexts! WS security standard revisited

SOAP header carries security information (and other info as well)

Selective processing SAML

Statements about authorization, authentication, attributes

SAML & WS-Security & XACML Implementations available