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

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: Security flaw in how Outlook verifies digital signatures
    ... of course the headers cannot ... However digitally signing a document is ... go deep down in the certificate to find the real identity of the sender, ... > certificate was assigned that used it to sign or encrypt the BODY of the ...
    (microsoft.public.outlook)
  • ANN; axExplorerBar released
    ... rendering the look and feel of the ExplorerBar according to the active ... Group headers can have a custom header, ... - Custom Control Items: ExplorerBar groups can host your own controls, ...
    (microsoft.public.vb.controls)
  • ANN; axExplorerBar released
    ... rendering the look and feel of the ExplorerBar according to the active ... Group headers can have a custom header, ... - Custom Control Items: ExplorerBar groups can host your own controls, ...
    (microsoft.public.vb.controls)
  • Remail-To: address1@somewhere.com
    ... Whenever you encrypt ... Hash headers are additional finalheadersfinal headers you want added ... No Drive Time-Outs - If you're using an encrypted drive to store keys ... A reply-block (also referred to as an encrypted reply-block, ...
    (sci.crypt)
  • Re: Force user to use outlook and custom organizational form
    ... Encrypted messages using custom forms are ... not compatible with mail clients other than Outlook. ... IPM.Note messages before you sign or encrypt them. ...
    (microsoft.public.exchange.development)