1. ® IBM Software Group © IBM Corporation WS-Policy Attachment- spec overview Maryann Hondo IBM

2. IBM Software Group | WebSphere software Policy Attachment Terminology Policy Subject – A Policy Subject is an entity (e.g., an endpoint, message, resource, interaction) with which a Policy can be associated. Policy Scope – A Policy Scope is the collection of Policy Subjects to which a Policy may apply. Policy Attachment – A Policy Attachment is a mechanism for associating Policy with one or more Policy Scopes. Effective Policy – An Effective Policy, for a given Policy Subject, is the resultant combination of relevant policies. The relevant policies are those attached to Policy Scopes that contain the Policy Subject.

3. IBM Software Group | WebSphere software Two attachment models ( the first…in the definition) The first allows XML-based descriptions of resources (represented as XML elements) to associate Policy as part of their intrinsic definition. Two alternatives: 1.a global attribute that allows Policy Expressions to be attached to an arbitrary XML element. –The following is the schema definition for the wsp:PolicyURIs attribute: –The following is an example <MyElement wsp:PolicyURIs=" http://www.fabrikam123.com/policies#RmPolicy http://www.fabrikam123.com/policies#X509EndpointPolicy" />

4. IBM Software Group | WebSphere software Attachment model 1 alternative 2 2.XML elements may use the wsp:Policy or wsp:PolicyReference elements directly as children, …an alternative way of attaching the policies in the above example, using child elements, would be as follows: <wsp:PolicyReference URI="http://www.fabrikam123.com/policies#RmPolicy" /> <wsp:PolicyReference URI="http://www.fabrikam123.com/policies#X509EndpointPolicy" />

5. IBM Software Group | WebSphere software Attachment model 2 (external attachment) The second attachment model, allows Policies to be associated with arbitrary Policy Subjects independently from their definition. This mechanism allows Policies to be associated with a Policy Subject independent of that subject's definition and/or representation through the use of a element. –This element has three components: –the Policy Scope of the attachment, –the Policy Expressions being bound, –and optional security information.

6. IBM Software Group | WebSphere software Attachment model 2 The following is the pseudo-schema for the element: + (... |... ) +... ?... Policy scope Policy expressions Security information Using XML expression Policies may be associated with subjects arbitrarily using a domain expression to describe the subjects e.g. A sequence of messages, a group of endpoints

7. IBM Software Group | WebSphere software Attachment Model 1 - WSDL WSDL attachment Policies may be embedded within a WSDL document And/or referenced from specific points in the WSDL to express specific constraints Four effective scope granularities – Service, Endpoint, Operation and Message

8. IBM Software Group | WebSphere software Clarifications The RECOMMENDED means of associating a Policy with a Policy Subject that has a WSDL 1.1 [WSDL 1.1] description is to attach a reference to the Policy within the WSDL component corresponding to the target Policy Subject.WSDL 1.1 WSDL/1.1 disallows the use of extensibility elements on certain elements and the use of extensibility attributes on others. However, the WS-I Basic Profile 1.1 [BP 1.1] overrules this restriction and allows element extensibility everywhere.BP 1.1 Therefore, the Policy reference SHOULD be attached using as child element unless it is absolutely necessary to maintain the original WSDL 1.1 restriction, in which case the @wsp:PolicyURIs attribute should be used for those restricted cases. If it is necessary to include the actual Policy Expressions within the WSDL description itself, it is RECOMMENDED that their elements be included as children of the element, and referenced using the mechanisms just described. Alternatively, the Policy Expressions MAY be made available through some other means, such as WS- MetadataExchange [WS-MetadataExchange].WS-MetadataExchange To ensure that consumers of Policy-annotated WSDL elements are capable of processing such Policy Attachments, attachments using SHOULD be marked as a mandatory extension (e.g., with a @wsdl:required="true" attribute).

9. IBM Software Group | WebSphere software WSDL 1.1

10. IBM Software Group | WebSphere software Example- stock quote (01) <wsdl:definitions name="StockQuote" ….. (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) SecurityPolicy Assertions

11. IBM Software Group | WebSphere software (26)<wsdl:import namespace="http://www.fabrikam123.com/stock" location="http://www.fabrikam123.com/stock/stock.wsdl" /> (27) (28)<wsoap12:binding style="document" (29)transport="http://schemas.xmlsoap.org/soap/http" /> (31) (32) (33) (34) (35) (36)<wsp:PolicyReference URI="#SecureMessagePolicy" wsdl:required="true" /> (37) (38) (39) (40)<wsp:PolicyReference URI="#SecureMessagePolicy" (41)wsdl:required="true" /> (42) (43) (44) (45) Attachment points

12. IBM Software Group | WebSphere software Effective policy for Message Subject The Effective Policy of a specific input message for a specific port would be the merge of the wsdl:message element defining the message type, the wsdl:portType/wsdl:operation/wsdl:input element, and the corresponding wsdl:binding/wsdl:operation/wsdl:input element for that message. Since a wsdl:message may be used by more than one wsdl:portType, it is RECOMMENDED that only policies containing abstract (i.e., binding independent) assertions should be attached to this type of element. Since wsdl:input, wsdl:output, and wsdl:fault elements in a wsdl:portType/wsdl:operation may be used by more than one binding, it is RECOMMENDED that only policies containing abstract (i.e., binding independent) assertions should be attached to these types of elements.

13. IBM Software Group | WebSphere software WS-Policy Attachment-UDDI V2 When attaching a Policy to a UDDI entity a Policy Scope is implied for that attachment. The Policy Scope only contains the Policy Subjects associated with that entity, and not those associated with the children of that entity. This Policy is the entity's Element Policy.

14. IBM Software Group | WebSphere software Service Policy Subject Endpoint Policy Subject Service Provider

15. IBM Software Group | WebSphere software Each Policy Assertion contained within a UDDI entity's Element Policy should have the correct semantic such that the subject for that assertion is that UDDI entity. For example, assertions that describe behaviours regarding a service provider should only be contained within policies attached to a businessEntity structure. For UDDI tModels that represent Web service types, the [Element Policy] is considered an intrinsic part of the tModel and applies to all uses of that tModel. In particular, it MUST be merged into the Effective Policy of every bindingTemplate that references that tModel. Policies that apply to deployed Web services (bindingTemplates) are only considered in the Effective Policy of that deployed resource itself WS-Policy Attachment-UDDI

16. IBM Software Group | WebSphere software Example of categoryBag use Using the Remote Policy Reference category system, one can then associate a Policy Expression with a businessEntity, a businessService, and a tModel using the entity's categoryBag. For example, associating the Policy Expression that is identified by the URI http://www.example.com/myservice/policy with a businessService is done as follows:... <keyedReference keyName="Policy Expression for example's Web services" keyValue="http://www.example.com/myservice/policy" tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" />

17. IBM Software Group | WebSphere software Example for BindingTemplate A different approach has to be taken to associate a Policy Expression with a bindingTemplate, since bindingTemplates do not contain a categoryBag in UDDI Version 2. Therefore, the bindingTemplate's tModelInstanceInfo and instanceParms MUST be used as follows... <tModelInstanceInfo tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" > http://www.example.com/myservice/policy

18. IBM Software Group | WebSphere software Service Policy Subject Message Policy Subject Operation Policy Subject Endpoint Policy Subject Service Provider WSDL

19. IBM Software Group | WebSphere software UDDI V3- enhancements tModelKeys of the pre-defined tModels are migrated to domain-based keys. (The migration is unique since the Version 2 keys introduced in this specification are already programmatically derived from the Version 3 keys given below) The tModelKey for the Remote Policy Reference tModel changes from "uuid:a27078e4-fd38-320a-806f-6749e84f8005" to "uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03". The tModelKey for the WS-Policy Types tModel changes from "uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" to "uddi:schemas.xmlsoap.org:policytypes:2003_03". The tModelKey for the Local Policy Reference tModel changes from "uuid:a27f7d45-ec90-31f7-a655-efe91433527c" to "uddi:schemas.xmlsoap.org:localpolicyreference:2003_03".

20. IBM Software Group | WebSphere software Binding Templates V3 Second, rather than putting Policy Expression references in a bindingTemplate's tModelInstanceInfo, they are added to the bindingTemplate's categoryBag, analogous to the mechanism described for other UDDI entities. For example, the example bindingTemplate from section 5.1 would be changed as follows:... <keyedReference keyName="Policy Expression for example's Web services" keyValue="http://www.example.com/myservice/policy" tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03" />

21. IBM Software Group | WebSphere software Wildcards & Security inquiries for reusable Policy Expression tModels and UDDI entities that are associated with remote Policy Expression is enhanced by the wildcard mechanism for keyValues in keyedReferences. For example, searching for all Policy Expression tModels whose URI starts with http://www.example.com, the following find_tModel API call can be used: <keyedReference keyValue="http://www.example.com" tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03" /> Fourth, all UDDI entities may be digitally signed using XML digital signatures [XML-Signature]. Publishers who want to digitally sign their Policy Expression tModels or Policy Expression references in UDDI MUST use the Schema-centric canonicalization algorithm [SCC14N].XML-SignatureSCC14N