Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / April 2006

Tip: Looking for answers? Try searching our database.

WSE3 Custom Policy Assertion / Filter : SecurityPolicyAssertion vs. PolicyAssertion

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Howard Hoffman - 12 Apr 2006 19:34 GMT
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
Steven Cheng[MSFT] - 13 Apr 2006 12:54 GMT
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.)


Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.