WS-Security Additional Material

Security Element: enclosing information n UsernameToken block u Defines how username-and-password info is enclosed in SOAP u Password must be protected against eavesdroppers (enc) and replay (timestamp/nonce) n BinarySecurityToken block u Encloses binary data u An X.509 certificate or a Kerberos ticket u Has an identifier (Id), a value (ValueType), and an encoding (EncodingType) u XML Signature KeyInfo may point to a certificate used in signing using a Reference to its Id. u Similar for XML Encryption. n So we can sign/encrypt data with a certificate in the header.

ID References n A new global attribute: wsu:Id attribute u.. u Note that the SOAP processor needs to support this u wsu:id a WS-Security namespace (wssecurity- secext-1.0.xsd) u Recipients do not need to understand the full schema of the message for processing the security elements u Two wsu:Id attributes within an XML document MUST NO have the same value n Recommended that wsu:Id is used instead of a more general transformation, especially XPath

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

Signing Messages n Multiple signature entries MAY be added into a single SOAP Envelope within one header block u MUST be prepended to the existing content n elements contained in the signature should refer to a resource within the enclosing SOAP envelope n u How to locate a key in a security token? u Extensible mechanism that provides an open content model for referencing security tokens u Specification considers only use in a header block n New reference option for XML signature u STR Deference Transform F Applied to a SecurityTokenreference F Means that the output is the token referenced by the element, not the element itself F You can conveniently locate and sign security tokens anywhere in the header

XML Encryption Example

Encryption Public keyPrivate key Asymmetric Key Pair EncryptDecrypt

XML Encryption ? ? ? ?

Example n SOAP Envelope u SOAP Header F WS Security Security token (a certificate) Encryption key (passing symmetric key) Signature u SOAP Body F Encrypted content

Overall message structure Security block

1. Binary security token T08:42:00Z <wsse:BinarySecurityToken ValueType="...#X509v3" wsu:Id="X509Token" EncodingType="...#Base64Binary"> ABCDEF

2. Passing encryption key <wsse:KeyIdentifier EncodingType="...#Base64Binary" ValueType="...#X509v3"> ABCDEF We are using another certificate for asymmetric crypto. This one is for symmetric Encrypted symmetric key Reference to cipher data

3. Actual signature <ds:CanonicalizationMethod algorithm=" … Exclusive canonicalization References & digests to data Reference to certificate.

<ds:CanonicalizationMethod Algorithm=" 3. SignedInfo in more detail

4. Actual message body <xenc:EncryptedData Type=" wsu:Id="enc1"> <xenc:EncryptionMethod Algorithm="

SAML Examples

Attribute assertion n An issuing authority asserts that: u subject S u is associated with attributes A,B,.. u with values ”a”,”b”,… n Typically this would be gotten from an LDAP repository u ”john.doe” in ”example.com” u is associated with attribute ”Department” u with value ”Human Resources”

Example attribute assertion <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe" /> <saml:Attribute AttributeName="PaidStatus" AttributeNameSpace=" PaidUp

Authorization decision assertion n An issuing authority decides whether to grant the request u by subject S u for access type A u to resource R u given evidence E n The subject could be a human or a program n The resource could be a web page or a web service, for example

Example authorization decision assertion <saml:AuthorizationStatement Decision="Permit" Resource=" <saml:NameIdentifier SecurityDomain="example.com" Name="johndoe" />