1 / 20

WS-Security Additional Material

WS-Security Additional Material. Security Element: enclosing information. UsernameToken block Defines how username-and-password info is enclosed in SOAP Password must be protected against eavesdroppers (enc) and replay (timestamp/nonce) BinarySecurityToken block Encloses binary data

chenoa
Télécharger la présentation

WS-Security Additional Material

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WS-Security Additional Material

  2. Security Element: enclosing information • UsernameToken block • Defines how username-and-password info is enclosed in SOAP • 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.

  3. 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

  4. Signatures • Does not use the Enveloped Signature Transform • So sig does not envelope signed data • Due to mutability of SOAP header • Does not use the Enveloping Signature • So sig is not appended as a child to the document • The sig is appended to the security block • Explicitly include the elements to be signed • Allows for extensions, multiple signatures, etc.

  5. 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> • How to locate a key in a security token? • Extensible mechanism that provides an open content model for referencing security tokens • Specification considers only use in a header block • New reference option for XML signature • STR Deference Transform • Applied to a SecurityTokenreference • 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

  6. XML Encryption Example

  7. Encrypt Decrypt Public key Private key Asymmetric Key Pair Encryption

  8. 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>

  9. Example • SOAP Envelope • SOAP Header • WS Security • Security token (a certificate) • Encryption key (passing symmetric key) • Signature • SOAP Body • Encrypted content

  10. Security block 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> 1. 2. 3. 4.

  11. 1. Binary security token <wsse:Security> <wsu:Timestamp wsu:Id="T0"> <wsu:Created> 2001-09-13T08:42:00Z </wsu:Created> </wsu:Timestamp> <wsse:BinarySecurityToken ValueType="...#X509v3" wsu:Id="X509Token" EncodingType="...#Base64Binary"> ABCDEF.... </wsse:BinarySecurityToken> <xenc:EncryptedKey>...</xenc:EncryptedKey> <ds:Signature>...</ds:Signature> </wsse:Security>

  12. 2. Passing encryption key We are using another certificate for asymmetric crypto. This one is for symmetric <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> Encrypted symmetric key Reference to cipher data

  13. 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.

  14. 3. SignedInfo in more detail <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>

  15. 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>

  16. SAML Examples

  17. 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”

  18. 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>

  19. 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

  20. 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>

More Related