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
Hi Howard,
Welcome to the MSDN newsgroup.
Regarding on the custom PolicyAssertion for WSE 3.0, I think whether you
should use PolicyAssertion or SecurityPolicyAssertion depend on the work to
de in the custom assertion. You can have a look at the WSE assertion
architecture:
#WSE Architecture
http://msdn.microsoft.com/library/en-us/wse3.0/html/5c044f61-7fdc-48f3-bf65-
b31201f0e614.asp?frame=true
In the request/response processing stack, different kind of assertion is
designed to hook the message at different stage. Also, the
secuirtyAssertion provide some additional methods for process securing and
verifying work on the message which will be called by the WSE runtime.
In addition, for the security token, the
SoapEnvlelope.Context.Credentials.UltimateReceiver will not always return
the current client-token in some condition. For example, when we have
configured to EstablishSecurityContext, then, after the first
request/response communication, the authenitcation token will be cached in
the CredentialContext. e.g:
RequestSoapContext.Credentials.GetSecurityContextToken
Hope this helps.
Regards,
Steven Cheng
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Signature
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)