Category Archives: WSE

Some Web Services Don’ts

After the XML DevCon was over, Dare Obasanjo said it’s time for some best practices on web services, not just “how to”. I wasn’t the only one to agree.

Don Smith writes today about two Web Services Don’ts. Both things that I Do. Uggh. Well kind of. Don says to put all of the business logic for a web service in a separate dll. I definitely have all of the code in separate classes as opposed to in the code behind of my web service asmx file, but I compiles those classes into the same DLL.

So this is a little different than “how to“. When and why is still one to look for.

Hey, at least I don’t fail the highlighted “don’t” in the current Glamour’s Dos and Donts!



Posted from BLInk!

Thank you Hervey

Hervey had to listen to me whine about this one. I have a remote web server and could not create policy files from the settings tool.

“The Security Settings Wizard can support creating Policy files for remote service.”

thanks! It’s minor, but helpful.

A quick perusal of the readme which Hervey Wilson has on his blog, shows some helpful stuff with X509 tokens (like friendly names) some help with managing custom security tokens

ok ok back to my ado.net 2.0 now



Posted from BLInk!

My next target on the WSE2 dive

Each time I talk to people about WSE2 in my presentations, I mention that we are relieved of the dependency on HTTPS and not only can we work with HTTP, but we also get to work with TCPIP naturally in the API. I have seen Keith Ballinger demo this twice now but have not played with it myself and am really curious about it. Pal and plumber, Ali Aghareza was at my talk on Monday night and it was the piece that also piqued his interest.

Posted from BLInk!

X509 Certificatates, WSE2 and JWSDP

I’m so happy I don’t have any *real* interop to do with WSE2 (yet). I want to learn it first, then dig into the harder stuff (and let’s not forget that this harder stuff, the interop, is the true intention of the WS* specs and therefore of WSE2, even if we do find it to be a nice neat way to deal with ws security in our .net to .net apps). Anyway, Simon Guest reports an issue with using X509 certificates other than the quickstart ones supplied with the SDK when interoping with JWSDP.

Posted from BLInk!

Digital Signatures at DevConnections

I had an awful moment in my WSE talk at ASPConnections thanks to great difficulty sleeping the previous night, so I want to be sure to write out my explanation of how a digital signature works here.

I have what I know is a terrific visual diagram to help explain digital signatures. What confused me when the slide popped up is seeing a private key next to the word encryption, which is correct for digital signatures but not for normal encryption. I had just walked the encryption diagrams and then hit the digital signing slide, saw that private key and my first thought was “but we don’t encrypt with a private key, we do it with a public key.” I really froze. In reality, my slide was right as I absolutely knew what I was talking about. Unfortunately i did not just allow myself to get past that moment of doubt. (which is a whole different topic about the balance of my knowledge, my presentation skills (both pretty good) and my confidence in them.)

So here’s the deal with why we are encrypting with the private key in this case. You can encrypt with any key you want, but you choose between them depending on your goals.

Encryption to achieve confidentiality: In this more common encryption scenario where we are trying to hide a message from prying eyes, we encrypt with the public key so that only the owner of the private key is able to decrypt. Anyone can see the message, but they won’t have the ability to decrypt it and view its’ actual contents.

Encryption as part of a digital signature: When digitally signing a message, we are creating a copy of the message body, hashing it (remember hashing can’t be undone) and then encrypting the hash. In the end, the validation is to ensure that the hash of the received message body matches this hash that we have sent along with the message body. If someone has mucked with the body or the hash (or both) there is no way that there will be a match on the other end. The encryption of the hash is done with a private key and then undone with the public key from the pair.

So this begs the question, why bother encrypting it if anybody can decrypt it? By encrypting with the private key, the recipient is absolutely assured that it was the sender (the only person with the private key) who created the digest. Think of this scenario: some devilish person could grab the message on its’ way, modify the message body and then create a new digest of that body. That would mean the digest would match the body when it’s received. But, that devilish person doesn’t have the correct private key to create the digest with. The recipient’s public key would recognize that immediately and the message would be invalidated.

So the process of signing doesn’t prevent anyone from mucking with the data (nor from even looking at the data – as this is the job of encrypting the message body), but just acts as a big red flag if the received message has been “violated” along the way.

Along those same lines, it’s good to note that encrypting a message body may prevent the wrong person from reading the actual data, but it is no guarantee that someone hasn’t taken the string of cipher text and altered it in anyway.



Posted from BLInk!

Encrypting UsernameTokens in WSE2

Thanks Benjamin for this info on how to encrypt a UsernameToken. I didn’t happen to see it anywhere else. I mostly liked looking at the soap message to see the effect (note that username=”John”, password=”Doe” and I am hashing the password in both cases and then encrypting the UsernameToken in the AFTER). Cool! I love this stuff. It’s like a big game. Based on the length of the encrypted UsernameToken, can you tell what I used to encrypt it with?

BEFORE

<wsse:UsernameToken wsu:Id=”SecurityToken-87259cd0-5a08-4a51-881e-fa901b96d5d9>
  <wsse:Username>john</wsse:Username>
  <wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest>z1YyKPkZdyPd0Hfs86gKWgQRurs=</wsse:Password>
  <wsse:Nonce>14KcMOY5cCTeMCTNPeCypA==</wsse:Nonce>
  <wsu:Created>2004-11-02T22:35:43Z</wsu:Created>
  </wsse:UsernameToken>
 
and AFTER
<wsse:UsernameToken wsu:Id=”SecurityToken-428cde88-3f56-47bd-8d09-e5efef45fca3>
<xenc:EncryptedData Id=”EncryptedContent-caa96918-e4ee-41c0-bafc-9b9740c6feea Type=”http://www.w3.org/2001/04/xmlenc#Content xmlns:xenc=”http://www.w3.org/2001/04/xmlenc#>
  <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes128-cbc />
<xenc:CipherData>
  <xenc:CipherValue>4xon7GAwNMsX3hU9kJ2atKGCf3bVbj/W6G5JsLV2lirb
WPyLuXcVG1bhzxeY6RPB1sElmVKMCz6iqfsC1yP
q/+HjhDKb5dB8h1NwPMSIkFbIkikHl3RyXSgUhtF
xUayFNAsef/Nq6XqN4WqwjWFG+x6il86Mf/x3O
IsojxHxVrqkyNbMw5OmHjbQBiM8bYFIpEDnk
1bYXB7zerytLP1zhPkBL+91ZptyTdZI2m3kFqc5e
/wtyFQInZ02ePhfUDPTc0jSlHDLPfDUN/doEkexe
Q264gYjWzXq1jaSFptxLDzcgOoH3f9AoQKsCitl
wo3tY2rLnK8lLgUOhjqbNV2FIiTwV/7aAVzhNmL
WzZdnBHRtA82X3jiqMtrvcyG2D0IDYfzFdLevp1
QPyil6Q9vaGr4I3yaUlqcgL+Ap5xn52lupxC+rv
Jv+xL2Xc9vKJaICsx8ib4ThGLod/damll3XO/1fbho1
NUU06nbMplzcifajNaVRsM4GbdLFsQfwp5rY1mePJpsjGq
m2hw7c1yxnlu4hCjDLdaxQU0H0IbPOlCufi6TT9jU+nPn
sCYg8p6sZXtKAoA4LAhgyKRduJMJmyV0Kjdh1pRUy4X
HKWxW1cxU/k4fC5VYaaDIpK6WK3eXcyoQ/RTRUzW4f
qeLgrUr6qXSSFF7WqZb4M+ZQYqqLl5Geq8AgPJrMNKC
xp1R1kQBFGwCRMALLR6L8BV0QhJgyIczuFyXSlpjJNSH
YJqBvTAeMTZwiIsmZeLTqgIFnMQ11XuGk8sc/P70ByYJ
WNP0Axt1I1gpjONzV4cwgu//fZD6DCRC4YW4NDBQAL
J687nfezcENZuBAHqUOxb7d/PRHcgCX0C1ggso63eOg
3XWFrvN+QreU3xmAEGJNZJCJFXeav+mg52lzJGCV15
Dv85ziccHHctOUxLYjIbaD647NDM4=</xenc:CipherValue>
  </xenc:CipherData>
  </xenc:EncryptedData>
  </wsse:UsernameToken>


Posted from BLInk!

WSE2 in production app

Did I happen to mention that I have WSE2 running in a production app? We are replacing the old version of the app with the new one a few users at a time at the client site and on the laptops as well as at the few remote sites. They won’t know the difference, but I sure do!

Posted from BLInk!