Re: WSE 3.0 Policy and Encrypting Custom Headers (XML Encryption S

Paul,

Thanks. I did read the MSFT WS-I basic security profile document and
noticed this. Thanks for responding. We are probably going to leverage this
custom assertion.

Thanks again.

Todd

"Pablo Cibraro" wrote:

> Hi Todd,
> Maybe, you can take a look to this application
> http://practices.gotdotnet.com/projects/wsibsp.
> We made a custom assertion, which encrypts custom headers using X509
> certificates.( It is included in that project )
>
> Regards
> Pablo Cibraro
> Lagash Systems
> http://weblogs.asp.net/cibrax
>
>
> "Todd Clemetson" <Todd Clemetson@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:B1ADC929-AAF2-43AB-ABE9-EEB69AC7CE14@xxxxxxxxxxxxxxxx
> > Sidd,
> >
> > Thanks for your comments. I have a few other questions/comments inline
> > below:
> >
> > Todd
> > "Sidd [MSFT]" wrote:
> >
> >> Hi Todd,
> >>
> >> Answers to your questions are inline...
> >>
> >> Please let me know if you have any more questions.
> >>
> >> Thanks,
> >>
> >> Sidd [MSFT]
> >>
> >> "Todd Clemetson" <Todd Clemetson@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> >> message
> >> news:DD41EEFE-A90B-405B-BF04-5BE1785F2983@xxxxxxxxxxxxxxxx
> >> >I am curious if WSE 3.0 policy or any other features of WSE 3.0 make it
> >> > easier to encrypt custom soap headers to conform to the Xml Encryption
> >> > Spec.
> >> > I am currently using WSE 2.0 and see no other solution other than to
> >> > write
> >> > my
> >> > own routines to encrypt custom soap header items (e.g SamlToken, custom
> >> > localization header, etc). WSE 2.0 does allow the body and username
> >> > tokens
> >> > to be encrypted by specifying these items in the MessageParts element
> >> > of
> >> > the
> >> > policycache file, but you can't speciy any part of the soap header to
> >> > be
> >> > encrypted as you can with the Integrity policy (this is done via the
> >> > Integrity MessageParts element).
> >> >
> >> > if WSE 3.0 makes this easy then I will hold off on building a custom
> >> > solution and simply wait for the RC to be shipped. If it doesn't, I
> >> > need
> >> > to
> >> > get busy :>) Could anyone shed some light on this? Just to summarize
> >> > my
> >> > questions:
> >> >
> >> > 1) Does WSE 3.0 policy support encrypting custom headers?
> >>
> >> The policy assertions in WSE 3.0 do not support encrypting headers, but
> >> do
> >> support signing headers.
> >>
> >> > 2) If not, is there some other features in WSE 3.0 outside of poilicy
> >> > that
> >> > will make this easier (e.g. something that will produce encrypted XML
> >> > conforming to the XML Encryption Specification).
> >>
> >> Yes, you can always encrypt custom headers using code:
> >>
> >> Assuming you have a customer header <foo> ... </foo>, all you would need
> >> to
> >> do is
> >>
> >> 1) Add an wsu:Id attribute to the <foo> header. For instance, your header
> >> should look like:
> >>
> >> <foo wsu:Id="customHeader-123" />
> >>
> >> then, you would construct a "EncryptedData enc = new
> >> EncryptedData(encryptingToken, "#' + "customHeader-123");
> >> requestSoapContext.Current.Security.Elements.Add(enc);
> >
> > Very helpful. Thanks for the info. i bit the bullet and installed VS2005
> > beta2 and WSe 3.0 on my home machine to see what was available. I noticed
> > this class as well. Very nice!
> >> > 3) Did I miss the boat on WSE 2.0? Is there something in WSE 2.0 that
> >> > I
> >> > missed that allows me to do this?
> >> >
> >>
> >> In WSE 2.0 policy, you can do this via the message parts in a
> >> confidentiality assertion by specifying wsp:Header(a:foo) and this would
> >> encrypt only the top level children of the soap:Header. Let me know if
> >> you
> >> need a concrete example of this. Have you given this a shot?
> >
> > I did give this a shot and found it to not work. Note that the
> > documentation for WSE 2.0 says you cannot do this for confidentiality
> > assertions. See
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wse/html/b6d347fa-df13-40ee-925a-9bbb24eee1fb.asp.
> > It explicitly states that the body and UserNameToken are the only valid
> > values for the MessagePart element in this assertion. The MessagePart
> > element in the integrity assertion does support what you are stating by
> > specifying the custom header in the same manner. I did try this early on
> > and
> > didn't have any luck. Am I still missing something here.
> >
> >
> >>
> >> Let me know if you get stuck with any of these, and I'll be glad to help.
> >>
> >> > Your help is greatly appreciated.
> >> >
> >> > Thanks
> >> > Todd Clemetson
> >> >
> >> > I am trying to make a decision whether or not we need to roll our
> >> > solution
> >> > for encrypting items in our header
> >> >
> >> >
> >> > I have a number of items that get put int soap header (SamlToken,
> >> > localization info, etc) that need to be signed and encrypted. I
> >> > noticed
> >> > that
> >> > Policy in WSE 2.0 did not support enrypting custom headers
> >>
> >>
> >>
>
>
>
.

Relevant Pages

  • Re: hi
    ... always receives a SoapException instead of the original exception. ... I've created a custom exception assertion. ... SoapExceptions in my custom assertion. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Cubic eqn help
    ... Todd that is a nice way of showing the assertion is true. ... (refering to Cardano's formula) ...
    (sci.math)