WS – Security Policy Prabath Siriwardena Director, Security Architecture

Why we need a policy ? How come users get to know the security requirements of your web service? Web service may need client to authenticate Web service may need client to sign all his requests Client may need some part of the response from the service to be encrypted Client need the service to sign the entire response first and then encrypts

WS - Policy General framework for endpoints to express requirements. NOT just for security requirements Requirements are expressed in terms of a ‘Policy’ WS-Policy is a set of specifications providing a generalized mechanism for describing policy in a machine readable way.

WS-Policy & WSDL WSDL focuses on function descriptions Non-functional descriptions and QoS aspects are covered by WS-Policy Web services clients do not have a WSDL, yet WS- Policy also applies to web services clients

WS-Policy Framework WS-Policy, defines a framework for describing policy assertions. WS-PolicyAttachment, describes how policies are attached to resource [e.g. WSDL] WS-PolicyAssertions, describes a common set of assertions that are applicable across different domains.

WS-Policy Basic operators wsp:All wsp:ExactlyOne

WS-Policy -Example

and are commutative and are associative and are idempotent and are distributive WS-Policy

WS-SecurityPolicy Based on WS-Policy Various groups of policy assertions Expressed in WSDL Defines six policy assertions that apply to WS-Security To express security requirements of a Web service according to the WS-Policy spec – What needs to be protected – What tokens to use – Algorithms, reference types, etc..

Assertion Types Protection assertions Required Elements Assertion Token assertions Security Binding assertions Supporting token assertions Protocol assertions

Protection Assertions Specify what needs to be protected – Integrity Assertions – Confidentiality Assertions

Protection Assertions - Integrity SignedParts This assertion specifies the parts of the message that need integrity protection.

Protection Assertions - Integrity SignedElements This assertion is used to specify arbitrary elements in the message that require integrity protection. xs:string

Protection Assertions - Confidentiality EncryptedParts This assertion specifies the parts of the message that need confidentiality protection..

Protection Assertions - Confidentiality EncryptedElements This assertion is used to specify arbitrary elements in the message that require confidentiality protection. xs:string

Protection Assertion Example

Required Elements Assertion This assertion is used to specify header elements that the message MUST contain. …

Token Assertions Token assertions specify the type of tokens to use to protect or bind tokens and claims to the message. – UsernameToken – X. 509 – IssuedToken

Token Assertions - UsernameToken This element represents a requirement to include a UsernameToken

Token Assertions - IssuedToken This element represents a requirement for an issued token, that is one issued by some token issuer...

Token Assertions - IssuedToken This element represents a requirement for an issued token, that is one issued by some token issuer.

Token Assertions – X.509 This element represents a requirement for a binary security token carrying an X509 token.

Token Assertions – X.509

Token Assertions Token Inclusion – Never – Always – AlwaysToRecipient – Once

Token Assertions What we didn’t cover... – KerberosToken Assertion – SecurityContextToken Assertion – SecureConversationToken Assertion – SamlToken Assertion – HttpsToken Assertion

Security Bindings A set of properties that together provide enough information to secure a given message exchange. The bindings are identified primarily by the style of protection encryption used to protect the message exchange. A binding defines the following security characteristics: The minimum set of tokens that will be used and how they are bound to messages Any necessary key transfer mechanisms Any required message elements (e.g. timestamps) The content and ordering of elements in the wsse:Security header. Elements not specified in the binding are not allowed. How correlation of messages is performed securely (if applicable to the message pattern)

Security Binding Assertion AlgorithmSuite Assertion Layout Assertion TransportBinding Assertion SymmetricBinding Assertion AsymmetricBinding Assertion

AlgorithmSuite This assertion indicates a requirement for an algorithm suite

AlgorithmSuite

Layout This assertion indicates a requirement for a particular security header layout

Layout

TransportBinding Indicates that the transport layer is used to satisfy the security requirements......

TransportBinding

SymmetricBinding Indicates that the message layer is used to satisfy the security requirements Defines "Encryption Token" and "Signature Token" properties Where multiple messages are exchanged the tokens perform the same functions for all messages

SymmetricBinding

AsymmetricBinding Indicates that the message layer is used to satisfy the security requirements Defines “Initiator Token” and “Recipient Token” properties The Initiator Token is used for the message signature from initiator to recipient, and encryption from recipient to initiator. The Recipient Token is used for encryption from initiator to recipient, and for the message signature from recipient to initiator. Where multiple messages are exchanged the tokens perform different functions

AsymmetricBinding

SupportingTokens Services may require multiple sets of claims to be presented Corresponds to additional tokens in a message Supporting tokens are included in the security header and may optionally include additional message parts to sign and/or encrypt.

SupportingTokens

EncryptedSupportingTokens Encrypted supporting tokens are supporting tokens that are included in the security header and MUST be encrypted when they appear in the security header. Element encryption SHOULD be used for encrypting these tokens. The encrypted supporting tokens can be added to any SOAP message and do not require the “message signature” being present before the encrypted supporting tokens are added. Introduced in WS-Security Policy 1.2

SignedSupportingTokens Token specified under this assertion will be signed by the message signature.

SignedSupportingTokens If transport level security is used there won’t be any signature in the message.

SignedSupportingTokens

SignedEncryptedSupportingTokens Signed, encrypted supporting tokens are Signed supporting tokens that are also encrypted when they appear in the wsse:Security header. Element Encryption SHOULD be used for encrypting the supporting tokens. Introduced in WS-Security Policy 1.2

EndorsingSupportingTokens Endorsing tokens sign the message signature, that is they sign the entire ds:Signature element produced from the message signature and may optionally include additional message parts to sign and/or encrypt.

EndorsingSupportingTokens When transport level security is used – there is no message signature and the signature generated by the supporting token will sign the Timestamp.

EndorsingSupportingTokens

EncryptedEndorsingSupportingTokens Endorsing, encrypted supporting tokens are Endorsing supporting tokens that are also encrypted when they appear in the Security header. Element Encryption SHOULD be used for encrypting the supporting tokens. Introduced in WS-Security Policy 1.2

SignedEndorsingSupportingTokens Signed endorsing tokens sign the entire ds:Signature element produced from the message signature and are themselves signed by that message signature, that is both tokens (the token used for the message signature and the signed endorsing token) sign each other.

SignedEndorsingSupportingTokens When transport level security level is used there will be no message signature and the signature generated by the supporting token will sign the Timestamp.

EncryptedSignedEndorsingSupportingTokens Signed, endorsing, encrypted supporting tokens are signed, endorsing supporting tokens that are also encrypted when they appear in the wsse:Security header. Element Encryption SHOULD be used for encrypting the supporting tokens. Introduced in WS-Security Policy 1.2

WSS Assertions Specify supported version of WSS – sp:Wss10 – sp:Wss11 Specify supported token reference mechanisms via boolean properties Specify Signature Confirmation requirements for WSS 1.1

WSS10 Assertions

WSS11 Assertions

Trust Assertions Specify supported version of WS-Trust and associated properties – sp:Trust10

Trust Assertions

Associating a Policy Define the policy within the WSDL [ in the WSDL it self or pointed to from the WSDL] Stand alone policy which points back to the web service or services associated with it – Arbitrary Resource Attachment

Associating a Policy Arbitrary Resource Attachment

Associating a Policy Define the policy within the WSDL - Policy can be attached to different locations in the WSDL, which will give different meanings. - Policy that is attached higher in the hierarchy is inherited. - If lower level element has a policy defined for it, the parent’s attached policy will be merged with the child’s policy.

The Main Structure of WSDL xschema types … a set of operations communication protocols a list of binding and ports

Policy Subjects WS-Policy Attachment defines various attachment points for policy. – Message Policy Subject – Operation Policy Subject – Endpoint Policy Subject

Message Policy Subject wsdl:message wsdl:portType/wsdl:operation/wsdl:input wsdl:portType/wsdl:operation/wsdl:output wsdl:portType/wsdl:operation/wsdl:fault

Operation Policy Subject wsdl:portType/wsdl:operation wsdl:binding/wsdl:operation

Endpoint Policy Subject wsdl:portType wsdl:binding wsdl:port

Associating a Policy Define the policy within the WSDL <wsdl:message name=“LookupResponse” wsp:PolicyRef=“Q1” />

Associating a Policy Define the policy within the WSDL

Associating a Policy Define the policy within the WSDL

Normal Form Policy as a collection of policy alternatives A policy alternative as a collection of assertions Composed of a single operator containing one or more operators.

Normal Form

Nested Assertions Nested assertions describe requirements and alternatives for the enclosing assertion elements.

Nested Policy Normalization If an assertion in a normal form contains a nested policy, it can at most contain ONE policy alternative.

Nested Policy Normalization

Compatibility Two assertions are compatible if the QName value of one assertion matches with a Qname value of the other assertion. Two policies are compatible if an alternative in one is compatible with an alternative in the other. If two policies are compatible, their intersection is the set of the intersections between all pairs of compatible alternatives, choosing one alternative from each policy. If two policies are not compatible, their intersection has no policy alternatives.

Policy Intersection Useful when two or more parties express policy and want to limit the policy alternatives to those that are mutually compatible. Intersection takes two policies and returns a policy. There are two modes for intersection: strict and lax. How the mode is selected or indicated for the policy intersection is outside the scope of this specification.

Policy Intersection If the mode is strict, two policy alternatives A and B are compatible: if each assertion in A is compatible with an assertion in B, and if each assertion in B is compatible with an assertion in A. If the mode is lax, two policy alternatives A and B are compatible: if each assertion in A that is not an ignorable policy assertion is compatible with an assertion in B, and if each assertion in B that is not an ignorable policy assertion is compatible with an assertion in A.

lean. enterprise. middleware