Observations on WSPolicy Ashok Malhotra Oracle Corporation Based

Observations on WS-Policy Ashok Malhotra Oracle Corporation

Based on Developer Experience and Interactions with Customers

Operators allow assertions from disparate domains Ÿ WS-Policy allows operations to combine assertions from disparate domains <wsp: Exactly. One> <wssp: x 509 …. /> <p 3 p: some. Privacy. Assertion /> </wsp: Exactly. One> Ÿ Like saying -- add (5, “hello. world”) -- > type error Ÿ Problems not detected early at policy syntax checking time but later at policy execution time Ÿ Suggestion: operators can only combine assertions from a single domain e. g. message. Protection

Embedded policies too general Ÿ WS-Security. Policy allows embedded policies to further qualify an assertion <sp: Username. Token sp: include. Token =“…”> <wsp: Policy> <wsp: Hash. Password /> <wsp: Require. Derived. Keys /> </wsp: Policy> </sp: Username. Token> Ÿ Idea of qualifying assertions is good Ÿ But embedded <wsp: Policy> too general as anything can go in a policy Ÿ Again, the problem is that nonsense policies can be authored and will not be caught until policy deployment time. Ÿ Suggestion: allow only specific qualifying child elements for each assertion

What Policy Does a Message Follow? Ÿ How do we figure out what policies a message adheres to? Ÿ There is an assumption that the message header indicates the policies being followed. Ÿ Not always possible because some policies are not reflected in message content such as auditing, logging, privacy. Ÿ Suggestion: allow messages to point to the policy the adhere to

Allow messages to refer to policy expressions Ÿ Useful if policy intent not reflected in message content Ÿ For example, informational policies such as privacy, logging, auditing Ÿ For long-running conversations, assert policy has not changed

Allow messages to refer to policy expressions Ÿ Policy usage model -- client and server intersect policies and decide on what policy alternative to follow Ÿ Assumes all messages in sequence follow the same policies Ÿ If some messages, e. g. first message deviate from agreed-upon policy they should be able to say so Ÿ Extension: allow messages to indicate the policy they follow as well as the policy they want the response to follow

Matching Policy Assertions Ÿ WS-Policy says that the semantics of matching policy assertions depends on the specific assertion type Ÿ No guidance from the specification Ÿ If each implementation can define matching semantics for an assertion type independently then clients and servers may have trouble coordinating policies if they define different assertion semantics for the same assertion type

Matching Policy Assertions Ÿ Assertion without embedded policy does not match same assertion with embedded policy Thus: <sp: Username. Token sp: include. Token =“…”> <wsp: Policy> <wsp: Hash. Password /> <wsp: Require. Derived. Keys /> </wsp: Policy> </sp: Username. Token> does not match <sp: Username. Token sp: include. Token =“…”> </sp: Username. Token> Ÿ Ÿ Should assertion without embedded policies match same assertion with all embedded policies? Issue before WS-SX

Policy Versioning Ÿ Some customers wants to store policies in a repository and manage them actively – – Policies will change over time Some global policies will override local policies Ÿ What we need: – – – Carefully spelt out overriding semantics Some sort of versioning attribute – perhaps start-date. Time, end-date. Time Ability to refer to policy artifacts by QName