Monthly Archives: January 2006

WSE: Security Token could not be retrieved vs. Permissions and some other Certificate hints

WSE

I was pushing a new WSE 3.0 web service to a test web server. Whenever I tried to authenticate I was getting “Security Token could not be retrieved” from the server.

WSE590: Failed to resolve the following Key Info …..

I knew the sample x509 server certificate was installed. I knew I had assigned read permissions to Network Service with the Certificate tool that comes with WSE.

It took me quite a while before I realized I had installed the certificate that came with WSE2 which is different than the certificates I had created with the WSE3 Setup in the Samples.

The data that made me finally realize it was that in the error message, it referred to the SHA-1 key identifier that the client had sent to the server to look for. But that was not the id of the server certificate.

So I uninstalled the wrong certificate and installed the correct one.

Now, as a test, I did not give permission to the Network Service account to access the certificate.

The message was very different:

WSE600: Unable to unwrap a symmetric key using the private key of an X.509 certificate. Please check if the account ‘NT AUTHORITY\NETOWRK SERVICE’ has permissions to read the private key of certificate with subject name ‘CN=WSE2QuickStatServer’ and the thumbprint…..

Now how specific is that? So I am now more confident that “security token could not be retrieved” is literally about FINDING the token, not using it, which can save me a lot of time if I make that mistake again!

Another thing that messed me up was that I had originally installed the certificate into the Current User’s store but I wanted it in Local Machine. You need to export and import certificates to make them work properly. But I didn’t know this and just dragged and dropped it to the Local Computer’s Personal Store instead. That was a no-no. The documentation (see the note in “How to: Make X.509 Certificates Accessible to WSE”) explains that when you do this, even if you use the certificate tool (or other means) to apply the ASPNET or NETWORK SERVICE perms, it won’t work. That is because the file associated to the certificate (and it is the file that is getting the permissions) does not get moved along with the certificate.



Don’t Forget: www.acehaid.org

Loading WinForms designer and a new form of dll hell in VS2005

dotNET

I have a VS2005 app that has assemblies with inherited forms and classes and there is something not quite right in my references that makes these particular assemblies very unstable.

This is a project that is being ported from VS2003.

When trying to load the form up in the designer, I frequently get “Could not load file or assembly” with a reference to a class file that has nothing to do with UI. And then I cannot access the design surface.

The referenced assembly is also referenced in the class from which the winform inherits. Sometimes I change the references (in both assemblies) to point to the compiled dll and then it’s working. Then somehow it breaks again. Sometimes, then pointing them both to the project, rather than the dll might fix this but maybe not. And I might battle it for a while then just have to walk away from the computer with my hands up in the air.

It’s very frustrating. Sometimes I can get away without having to have access to the design surface for whatever it is that I am doing. But I sure wish I could figure out what the heck the problem is, why it prevents me from loading up my winform and solve it once and for all.

Update: Today, this particular one was solved finally by referencing the DLL and not the project of the class that the form was inheriting from. If I had the time to try to figure out WHY, I would, but I know have to get back to working on this project.

Don’t Forget: www.acehaid.org

WSE 3.0 to Indigo: What about TCP transports?

WSE

WSE 2.0’s messaging API gave us the ability to host web services outside of IIS. Though it was very cool, I didn’t dig that too much because you had to give up all of the other WSE goodness that only worked in ASMX – including security.

In WSE 3.0, they changed this so that you could build ASMX web services, do all of the great security stuff and then host it outside of IIS – for me this meant TCP, though there are other transports you can use as well.

Now that I am using WSE3 to secure my web services that are currently being used (while we await WCF 🙂 ), I am trying to do so with WCF in mind. It is no secret that WSE 3.0 is going to be wire level compatible with WCF as this is was of it’s major design goals.

As I dig further into this, I learn that this is only true for HTTP but not the TCP hosted services. However, it is possible to write your own transport channel in Indigo specifically for this purpose and this is something that Yasser Shohoud and Kenny Wolf did at PDC (here’s the code for that). Luckily for me, I have the DVD because that was not a session I attended. I also missed Mark Fussell’s talk on moving messages between WSE 3 and Indigo since I had remembered it as a 10:15 session when it was in fact an 8:30 am talk (and had a leisurely breakfast instead – oops!). (Again, thank goodness for the DVDs)

At ASP Connections in April, I will be doing a talk about using WSE 3.0 so that the messages produced by WSE 3.0 today to secure your web services,  will still be valid when communicating with apps that use WCF.  So as I prepare for this, I will probably be sharing tidbits here and there.



Don’t Forget: www.acehaid.org

Attributes with property values in Visual Basic

dotNET

This got me once again. It’s really hard to remember!

When you do declarative programming in Visual Basic and you use attributes that have properties, you need to set the values on those properties. VB does this in a funny way.

Here is a C# attribute for BP (Basic Profile) Conformance in a Web Service:

[WebServicesBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

Setting the value of the ConformsTo property is a normal looking equals (=) operator.

But with VB, look at how we set the property

<WebServicesBinding(ConformsTo: = WsiProfiles.BasicProfile1_1)>

We put a colon in front of the equals sign.

This is not new to VB2005, but attributes are something I so rarely use (but will be using more and more as I do more WCF programming) that I forget from one year to the next.

I have never been able to find an explanation of why this is and only know it because I get a compiler error when I forget it ("named argument expected") and I have to see another example of it’s use somewhere before I realize it. Intellisense doesn’t give me a helping hand with it (as far as I have seen in vs2003 or vs2005). So, perhaps by writing this blog post, I can commit this to memory finally!

 

Don’t Forget: www.acehaid.org