T-110. 455 Network Application Frameworks and XML Web Service Security 06. 04. 2005 Sasu Tarkoma Based on slides by Pekka Nikander
Announcements n A list of papers to read for the final exam u u u n 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 Multihoming across the two versions of IP, in Proceedings of the Fifth European Wireless Conference, Mobile and Wireless Systems beyond 3 G (EW 2004), 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 n n n Review Requirements Security contexts WS security standard revisited SAML Summary
Extensible Rights Markup Standardization Groups Language W 3 C OASIS XML Common Biometric Xr. ML Provisioning Format (XCBF) Access Control e. Xtensible XML Key Management Markup Language (XACML) WS-Security Biometrics XML Encryption Specification XML Signature XKMS SAML Security Assertion Markup language XACML
know the message, Digital Signatures Need to and algorithm (f. e. digest, SHA 1) Message Digest SIGN Private key Message Signature Asymmetric Key Pair Message Digest VERIFY Public key Pass/Fail
XML Digital Signatures (cont. ) <Signature ID? > <Signed. Info> <Canonicalization. Method/> <Signature. Method/> (<Reference URI? > (<Transforms>)? <Digest. Method></Digest. Method> <Digest. Value></Digest. Value> </Reference>)+ </Signed. Info> <Signaturevalue></Signaturevalue> (<Key. Info>)? (<Object ID? >)* </Signature>
Encryption Encrypt Public key Decrypt Asymmetric Key Pair Private key
XML Encryption <Encrypted. Data Id? Type? Mime. Type? Encoding? > <Encryption. Method/>? <ds: Key. Info> <Encrypted. Key>? <Agreement. Method>? <ds: Keyname>? <ds: Retrieval. Method>? <ds: *>? </ds: Key. Info> <Cipher. Data> <Cipher. Value>? <Cipher. Reference URI? >? </Cipher. Data> <Encryption. Properties>? </Encrypted. Data>
Web Services Security Requirements n Access control to Web services u u u n WS-Security, XML-Signature SAML – Issuing and validation of SAML assertions Digital certificate validation Content-filtering XML u u u Filters based on data format (XSD) Filters based on content (XPath) Filters based on integrity (XML Signature)
Functional point of view XML Management Console Design and Deploy Security policies Authorization Authentication Content Checking Integrity Validation Routing XML ID Management LDAP PKI Single Sign-On Reporting Activity Alerting Secure logging
Security Contexts in Web Services n Remember Web Services goals: u u n Re-use existing services Combine services from several domains Security result: Must support several security domains u u SOAP intermediaries Reusing security tokens from one message in another message
Example 1: Pass subject details Security Context II Security Context I Web Browser HTTP POST Website Appl. Server SOAP Web Service Main Point: We need security within AND between security contexts!
Example 2: SOAP Routing Security Context II Security Context I SOAP HTTP SOAP SMTP Main Point: We need XML validation, encryption, and authentication between security contexts!
WS Security I n n Web Services Security: SOAP Message Security 1. 0 (Oasis Standard 2004) End-to-End security u n Selective processing u u u n Headers are decrypted and processed as needed Some parts are plain text Some are encrypted Some are signed How does it work? u SOAP header carries security information (and other info as well)
WS Security II n n 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 n n n 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 n n n 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 n Integrity mechanism designed to support multiple signatures Uses XML Signature and XML Encryption Syntax and semantics of signatures within a <wsse: Security> element u u n This is the security block in the SOAP header SOAP actor/role attribute is used to target header blocks Security element includes u u Security tokens Information about the use of XML Encryption & Signature in the SOAP header/body/combination
Security Header n May be present multiple times in a SOAP message u Must have different actor/role attribute values <? xml version="1. 0" encoding="utf-8"? > <soap: Envelope xmlns: soap="". . . " xmlns: wsu=". . . ” xmlns: wsse=". . . "> <soap: Header> <wsse: Security soap: must. Understand=”. . ”>. . </wsse. . . > </soap: Header> <soap: Body>. . . </soap: Body> </soap: Envelope> u u 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
Security Element: enclosing information n Username. Token block u u u n Binary. Security. Token block u u u n 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) Encloses binary data An X. 509 certificate or a Kerberos ticket Has an identifier (Id), a value (Value. Type), and an encoding (Encoding. Type) XML Signature Key. Info 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 n A new global attribute: wsu: Id attribute u u u n <any. Element wsu: id=”. . ”>. . </any. Element> Note that the SOAP processor needs to support this wsu: id a WS-Security namespace (wssecuritysecext-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 n Does not use the Enveloped Signature Transform u n n Due to mutability of SOAP header Does not use the Enveloping Signature Explicitly include the elements to be signed u Allows for extensions, multiple signatures, etc.
Canonicalization n n XML Canonicalization and Exclusive XML Canonicalization Problems u u u 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 n 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 n n Tries to figure out what namespaces are actually used and just copies those Does not look into attribute values or element content u n Useful when you have an XML document that you wish to insert into another XML document u n Can happen implicitly because XML processing tools will add xsi: type if schema subtypes are used Example: signed SAML assertion Should be used with WS-Security: SOAP Message Security (recommended)
Signing Messages n Multiple signature entries MAY be added into a single SOAP Envelope within one <wsse: Security> header block u n n <ds: Reference> elements contained in the signature should refer to a resource within the enclosing SOAP envelope <wsse: Security. Tokenreference> u n MUST be prepended to the existing content Extensible mechanism that provides an open content model for referencing security tokens New reference option for XML signature u STR Deference Transform F F 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 Open content model for specifying token. It could be XML, URI, … <wsse: Security. Token. Reference wsu: Id="Str 1">. . . </wsse: Security. Token. Reference>. . . We use the content here using <ds: Signature xmlns: ds="http: //. . . xmldsig#"> #STR-Transform and compute the <ds: Signed. Info> digest <ds: Reference URI="#Str 1"> <ds: Transforms> <ds: Transform Algorithm=". . . #STR-Transform">. . . </ds: Transform></ds: Transforms> <ds: Digest. Method Algorithm="http: //. . . #sha 1"/> <ds: Digest. Value>. . . </ds: Digest. Value> </ds: Reference> </ds: Signed. Info> <ds: Signature. Value></ds: Signature. Value> </ds: Signature>
Extended example n SOAP Envelope u SOAP Header F u WS Security • Security token (a certificate) • Encryption key (passing symmetric key) • Signature SOAP Body F Encrypted content
Overall message structure Security block <? xml version="1. 0" encoding="utf-8"? > <soap: Envelope> <soap: Header> <wsse: Security> 1. <wsse: Binary. Security. Token>. . . </wsse: Binary. . . > <xenc: Encrypted. Key>. . . </xenc: Encrypted. Key> 2. <ds: Signature> 3. <ds: Signature. Value>. . . </ds: Signature. Value> <ds: Key. Info>. . . </ds: Key. Info> </ds: Signature> </wsse: Security> </soap: Header> <soap: Body wsu: Id="body"> 4. <xenc: Encrypted. Data>. . . </xenc: Encrypted. Data> </soap: Body> </soap: Envelope>
1. Binary security token <wsse: Security> <wsse: Binary. Security. Token Value. Type=". . . #X 509 v 3" wsu: Id="X 509 Token" Encoding. Type=". . . #Base 64 Binary"> ABCDEF. . </wsse: Binary. Security. Token> <xenc: Encrypted. Key>. . . </xenc: Encrypted. Key> <ds: Signature>. . . </ds: Signature> </wsse: Security>
2. Passing encryption key <xenc: Encrypted. Key> We are using another certificate for asymmetric <xenc: Encryption. Method Algorithm=". . . #rsa-1_5"/> crypto. <ds: Key. Info> <wsse: Key. Identifier Encoding. Type=". . . #Base 64 Binary" Value. Type=". . . #X 509 v 3"> ABCDEF. . </wsse: Key. Identifier> </ds: Key. Info> Encrypted symmetric key <xenc: Cipher. Data> <xenc: Cipher. Value>. . . </xenc: Cipher. Value> Reference to cipher data </xenc: Cipher. Data> <xenc: Reference. List> <xenc: Data. Reference URI="#enc 1"> </xenc: Reference. List> </xenc: Encrypted. Key>
3. Actual signature <ds: Signature> <ds: Signed. Info> Exclusive canonicalization <ds: Canonicalization. Method algorithm="http: //. . . -exc-c 14 n#"/> <ds: Signature. Method algorithm="http: //. . . #rsa-sha 1"/> <ds: Reference URI="#T 0">. . . </ds: Reference> <ds: Reference URI="#body">. . . </ds: Reference> …. References & digests to </ds: Signed. Info> data <ds: Signature. Value>. . . </ds: Signature. Value> <ds: Key. Info> <wsse: Security. Token. Reference> <wsse: Reference URI="#X 509 Token"/> </wsse: Security. Token. Reference> Reference to certificate. </ds: Key. Info> </ds: Signature>
3. Signed. Info in more detail <ds: Signed. Info> <ds: Canonicalization. Method Algorithm="http: //. . . -exc-c 14 n#"/> <ds: Signature. Method Algorithm="http: //. . . #rsa-sha 1"/> <ds: Reference URI="#T 0"> <ds: Transforms> <ds: Transform Algorithm="http: //. . . exc-c 14 n#"/> </ds: Transforms> <ds: Digest. Method Algorithm="http: //. . . #sha 1"/> <ds: Digest. Value>. . . </ds: Digest. Value> </ds: Reference> <ds: Reference URI="#body"> <ds: Transforms> <ds: Transform Algorithm="http: //. . . exc-c 14 n#"/> </ds: Transforms> <ds: Digest. Method Algorithm="http: //. . . #sha 1"/> <ds: Digest. Value>. . . </ds: Digest. Value> </ds: Reference> </ds: Signed. Info>
4. Actual message body <soap: Body wsu: Id="body"> <xenc: Encrypted. Data Type="http: //www. w 3. org/2001/04/xmlenc#Element" wsu: Id="enc 1"> <xenc: Encryption. Method Algorithm="http: //www. w 3. org/2001/04/xmlenc#tripledes-cbc"/> <xenc: Cipher. Data> <xenc: Cipher. Value>. . . </xenc: Cipher. Value> </xenc: Cipher. Data> </xenc: Encrypted. Data> </soap: Body> </soap: Envelope>
Error Handling n n SOAP Faults are used to indicate faults Error scenarios u Security token type unsupported F F u Invalid security token F F u For example: security token corrupted or has invalid signature Fault code: Invalid. Security. Token Security token cannot be authenticated F F u Note: WS-Policy may be used to convey what security tokens can be understood by different parties Fault code: Invalid. Security (if contents of the header block cannot be processed) For example: given certificate cannot be validated Fault code: Failed. Authentication Security token unavailable F F For example: a certificate was referenced that could not be located Fault code: wsse: Security. Token. Unavailable
SAML n n SAML (Security Assertion Markup Language) u A XML-based framework (schemas) for the exchange of authentication and authorization information u A standard message exchange protocol F 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 u Authentication statements merely describe acts of authentication that happened previously Specified by OASIS
SAML in a nutshell n XML-based framework for exchanging security information u u u n 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. A Domain B User Service Authentication server A server B Using services in B from A? Authentication at B? Not acceptable!
Domain A Domain B User Service Authentication server A Authentication server B Timed updates Authentication server C Timed updates
SAML assertions n An assertion is a declaration of fact about a subject, e. g. a user u n SAML has three kinds, all related to security: u u u n n According to some assertion issues 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 n Issuer and issuance timestamp Assertion ID Subject u u n ”Conditions” under which assertion is valid u u n Name plus the security domain Optional subject information, e. g. public key SAML clients must reject assertions containing unsupported conditions Special kind of condition: assertion validity period Additional ”advice” u E. g. to explain how the assertion was made
Authentication assertion n An issuing authority asserts that: u u u n Caution: actually checking or revoking of credentials is not in the scope of SAML! u u u n Subject S was authenticated by means M at time T Password exchange Challenge-response Etc. It merely lets you link back to acts of authentication that took place previously
Example authentication assertion <saml: Assertion Major. Version="1" Minor. Version="0" Assertion. ID="127. 0. 0. 1. 1234567" Issuer="Example Corp" Issue. Instant="2005 -04 -04 T 09: 00 Z"> <saml: Conditions Not. Before="2005 -04 -04 T 09: 00 Z" Not. After=""2005 -04 -04 T 09: 05: 00 Z"/> <saml: Authentication. Statement Authentication. Method="password" Authentication. Instant="2005 -04 -04 T 09: 01: 00 Z"> <saml: Subject> <saml: Name. Identifier Security. Domain="example. com" Name="johndoe"/> </saml: Subject> </saml: Authentication. Statement> </saml: Assertion>
Attribute assertion n An issuing authority asserts that: u u u n subject S is associated with attributes A, B, . . with values ”a”, ”b”, … Typically this would be gotten from an LDAP repository u u u ”john. doe” in ”example. com” is associated with attribute ”Department” with value ”Human Resources”
Example attribute assertion <saml: Assertion. . . > <saml: Conditions. . . /> <saml: Attribute. Statement> <saml: Subject> <saml: Name. Identifier Security. Domain="example. com" Name="johndoe" /> </saml: Subject> <saml: Attribute. Name="Paid. Status" Attribute. Name. Space="http: //example. com"> <saml: Attribute. Value> Paid. Up </saml: Attribute. Value> </saml: Attribute. Statement> </saml: Assertion>
Authorization decision assertion n An issuing authority decides whether to grant the request u u n n 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: Authorization. Statement Decision="Permit" Resource="http: //example. com/res 123"> <saml: Subject> <saml: Name. Identifier Security. Domain="example. com" Name="johndoe" /> </saml: Subject> </saml: Authorization. Statement> </saml: Assertion>
Assertion type Description Asserts that subject S Authentication was authenticated by Assertion means M at time T Attribute Assertion Asserts that subject S is associated with attributes A 1, A 2, … with values V 1, V 2, . . . 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: Username. Token> <wsse: User. Name>abc</wsse: User. Name> <wsse: Password Type="wsse: Password. Digest"> xyzabc </wsse: Password> <wsse: Nonce> ap 2 oep 3 oaeap 1 </wsse: Nonce> </wsse: Username. Token>. . . </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: Binary. Security. Token Id="X 509 Token" xmlns: wsse=". . . secext" Value. Type="wsse: X 509 v 3" Encoding. Type="wsse: Base 64 Binary"> ABCDEF. . </wsse: Binary. Security. Token> <ds: Signature xmlns: ds=". . . xmldsig#"> <ds: Signed. Info>. . . </ds: Signed. Info> <ds: Signature. Value>. . . </ds: Signature. Value> <ds: Key. Info> <wsse: Security. Token. Reference> <wsse: Reference URI="#X 509 Token"/> </wsse: Security. Token. Reference> </ds: Key. Info> </Signature>. . . </wsse: Security>
A SAML Assertion in WS-Security SOAP Header xmlns: wsse="http: //. . . secext"> <wsse: Security <saml: Assertion xmlns: saml="urn: oasis: names: tc: SAML: 1. 0: assertion" Major. Version="1" Minorversion="0" Assertion. ID="Security. Token-123" Issuer="example. com" Issue. Instant="2005 -04 -04 T 09: 00 Z">. . . </saml: Assertion> <ds: Signature xmlns: ds=". . . xmldsig#">SAML does not allow the <ds: Signed. Info>. . . </ds: Signed. Info> use of the ID attribute with <ds: Signature. Value>. . . </ds: Signature. Value> elements, hence assertion <ds: Key. Info> Assertion. IDReference is used <wsse: Security. Token. Reference> <saml: Assertion. IDReference> Security. Token-123 </saml: Assertion. IDReference> </wsse: Security. Token. Reference> </ds: Key. Info> </Signature>. . . </wsse: Security>
Once the SAML authoriz. Has SOAP msg is ben made it may be included Intercepted. SAML query is into the SOAP message and formed, results determine used by the target WS. access. Identity info taken from request. There may be multiple Once the PDP has all PDP queries attributes WS request PEPs. the relevant from PIP (time of day, (SOAP) value, etc. ). PIP returns PEP information, it evaluates Web Service Policy Enforcement Pointand returns a an attribute assertion. rules SAML authoriz. SAML Authrz. Reply Assertion decision query SAML and XACML Info request PDP Policy Decision Point XACML Policy request PIP Policy Information Point Attribute assertion Policy (XACML) PRP Policy Retrieval Point Rules are combined: subjects, Policy Store and attributes. resources, (XACML) into XACML. Exported PAP Policy Admin. Point
Implementations n n n Trust Services Integration Kit (TSIK), Verisign u Java API for creating trusted services, includes a SAML API u http: //www. xmltrustcenter. org/developer/verisign/tsik/inde x. htm Apache XML-Security, Apache Software Foundation u XML Digital Signature and XML Encryption (Java, C++) u http: //xml. apache. org/security/ Web Services Enhancements 2. 0, Microsoft u. NET implementation of various WS Security specs. u http: //msdn. microsoft. com/webservices/building/wse/ Microsoft Passport, Microsoft u Single sign-on support XML Security Suite, IBM u XML Digital Signature, XML Encryption and XML Access Control Language (Java) u http: //www. alphaworks. ibm. com/tech/xmlsecuritysuite Sun. ONE Identity Server, Sun Microsystems u Supports Liberty’s federated identity and SAML
Web Services Enhancements 2. 0 n n n Implements many of the rules of the WS* specifications Works with HTTP and SOAP (Soap. Extensions) Supported specifications u n n WS-Security, WS-Security. Policy, WSSecure. Conversation, WS-Trust, WS-Referral, WS-Addressing, WS-Policy, WS-Attachments Supports signing/encrypting message elements and policies More information and downloads
Lecture Summary n Security contexts u u n WS security standard revisited u u n SOAP header carries security information (and other info as well) Selective processing SAML u u n Security needed within and between contexts XML validation, encryption, and authentication needed between security contexts! Statements about authorization, authentication, attributes SAML & WS-Security & XACML Implementations available
Скачать презентацию T-110 455 Network Application Frameworks and XML Web
19969641a39f20b725bd1003eb364f39.ppt