I'm implementing a custom authorization filter against the WSE3 stack.
My filter is similar to the Microsoft.Web.Services3.Design.AssertionAssertion except that it has finer granularity than WebService.
I originally attempted to implement the assertion and filter by subclassing SecurityPolicyAssertion and ReceiveSecurityFilter respectively. However, the state of the SoapEnvelope during the ReceiveSecurityFilter subclass's ValidateMessageSecurity override was not what I expected. Namely, SoapEnvelope.Context.Credentials.UltimateReceiver contained 0 client tokens.
I noticed from the WSE3 documentation that AuthorizationAssertion subclasses PolicyAssertion, rather than SecurityPolicyAssertion (and SoapFilter vs ReceiveSecurityFilter).
I changed my custom policy assertion implementation to also use the PolicyAssertion and SoapFilter. During my SoapFilter subclass's ProcessMessage override I now see that the SoapEnvlelope.Context.Credentials.UltimateReceive contains a valid client token. I'm happier now.
But I'm wondering what the ReceiveSecurityFilter has done to the SoapEnvelope with respect to the Client Token(s) that SoapFilter has not done.
I'm a tad worried that my implementation will break once Vista and WCF go final.
Thanks in advance,
Howard Hoffman
WSE3 Custom Policy Assertion / Filter : SecurityPolicyAssertion vs. PolicyAssertion
Manjax
This behavior is dependent upon any other security filter that you have in you processing pipeline. You can only parse the security header from the SOAP message once. In effect you should only have a single policy assertion derived from SecurityPolicyAssertion in your processing pipeline.
For instance, when you have a security Policy derived from SecurityPolicyAssertion you are not passed the security class for 2nd and subsequent ones, since it no longer exists in the message. The security information is held in envelope.Context.Security if you need this access to the parsed security context.
In your case, if you have use a WSE supplied security policy (e.g. UsernameOverCertificateAssertion) this parses the security header in the SOAP message and if the soapactor="" (which is the default) this sets the UltimateReceiver credential value accordingly. However is you create your own assertion derived from SecurityPolicyAssertion, you are saying that I will parse the security header and only after this has been processed can the UltimateReceiver credentials be set. This is why your assertion derived from PolicyAssertion works but the one from SecurityPolicyAssertion does not.
In general when creating you own custom policy assertions you either
1) Derive from PolicyAssertion which does not do any security header processing, but if you want security information after the header has been processed by another assertion you can get this from envelope.Context.Security
2) Or derive from one of the supplied WSE 3.0 security policy assertions and change the behavior. There is example in the Advanced quickstarts for WSE 3.0
3) Or Derive from SecurityPolicyAssertion and handle you own complete security header processing. Here you are back to the WSE 2.0 days of getting the security tokens and signatures from the message and deciding how to apply them to the message. Fine grained control, but more complex.
I suggest that you read this article although it does not describe the difference between using SecurityPolicyAssertion and PolicyAssertion which is described in the WSE 3.0 docs
http://msdn.microsoft.com/msdnmag/issues/06/02/WSE30/default.aspx
Thanks.
Mark Fussell
WSE Program Manager