T-110.455 Network Application Frameworks an XML Web Service Security 06.04.2005 Sasu Tarkoma Based on slides by Pekka Nikander
Jan 04, 2016
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!
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>
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