Jan/Feb CTP Deltas for Infocard

I have the code that used to work on the Jan CTP working again. It was hard work, for a sys-admin moonlighting as a programmer such as myself :-) I’m hoping that the assembly re-org is over for good — it will kill me if I have to do this again in a month. I also should mention that I think that the reorg was a really good idea, the new organization is a lot more intuitive.

I couldn’t have figured this out without the ‘breaking changes‘ link that I posted earlier. Since you don’t actually have my code, this will seem rather esoteric; however anyone who is wrestling with one of the errors I mention, or researching one of the classes affected should understand what I mean. BTW – any code shown is in C#.

Let’s start with the “dumb errors” and get them out of the way:

  • Don’t forget that you had to install the Feb CTP on a vanilla system – if you are using the certificates supplied in the Sept 2005 Resource Kit, make sure to:
    • Place the client and service certificate again
    • Set up the IIS virtual directory to host the logos of the certificate again (this is optional I believe, but still nice).

Next, let’s talk about new things that might screw you up:

  • You have to know to add project references for System.IdentityModel and System.IdentityModel.Selectors. They don’t appear on the nice little list  — I had to browse to C:\Program Files\Reference Assemblies\Microsoft\WinFx\v3.0 and choose them manually.
  • In the Sept 2005 Resource Kit, a note existed in the Programmers Guide saying that they had relaxed issuer requirements, and the certificate issuer did not have to be in the “Trusted Root CA” list. Apparently relaxation time is over — you MUST have a valid certificate chain now, one that can be traced to a valid root CA. If you don’t, you will get this exception:
    • X509 certificate (CN=Fabrikam) chain building failed. A certificate chain could not be built to a trusted root authority.
    • To satisfy this requirement, export the certificate for INFOCARD that is generated when you import Fabrikam.pfx, and re-import it into the “Trusted Certificate Authorities” portion of “LocalMachine”. You will know it is in the right place when you open up the original Fabrikam certificate and the details tell you that this certificate is properly chained.
  • I believe that the Feb CTP implements online certificate revocation checking by default for the first time (feel free to call me out on that, I come to that conclusion honestly, since revocation was not an issue for me in the Jan CTP and now it is/was). You have to set the default revocation mode to “NoCheck” instead of the now-default “Online” setting if you want things to work without revocation checking. Actual Code for setting this is listed later on in this entry. If you don’t change the setting, you may get an exception:
    • X509 certificate (CN=Fabrikam) chain building failed. The revocation function was unable to check revocation for the certificate.

Ok, let’s get to the actual Delta List:

Compilation Errors

  1. The type or namespace name ‘AuthorizationContext’ could not be found (are you missing a using directive or an assembly reference?)
    • Include “System.IdentityModel.Policy”
  2. The type or namespace name ‘ClaimSet’ could not be found (are you missing a using directive or an assembly reference?)
    • Include “System.IdentityModel.Claims”:
  3. The type or namespace name ‘ServiceEndpointCollection’ could not be found (are you missing a using directive or an assembly reference?) — or — The name ‘MetadataResolver’ does not exist in the current context
    • Include “System.ServiceModel.Description”
  4. Cannot declare variable of static type ‘System.ServiceModel.Description.MetadataResolver’ –or– Cannot create an instance of the static class ‘System.ServiceModel.Description.MetadataResolver’ –or– ‘System.ServiceModel.Description.MetadataResolver’ does not contain a definition for ‘RetrieveEndpoints’
  5. You probably have two lines similar to this:

    • MetadataResolver mexProxy = new MetadataResolver(mexAddress);
    • ServiceEndpointCollection endpoints = mexProxy.RetrieveEndpoints();

    Replace those lines with this line:

    • ServiceEndpointCollection endpoints = MetadataResolver.Resolve(mexAddress);

    And include “System.ServiceModel.Description”.

  6. The type or namespace name ‘InfoCardClientCredentials’ could not be found (are you missing a using directive or an assembly reference?)
    • Include “System.IdentityModel.Selectors”.
  7. ‘System.ServiceModel.Security.X509CertificateRecipientClientCredential’ does not contain a definition for ‘Certificate’
  8. Replace a line like this:

    • credentials.ServiceCertificate.Certificate = ((X509CertificateIdentity)ep.Address.Identity).Certificates[0];

    With a line like this:

    • credentials.ServiceCertificate.DefaultCertificate = ((X509CertificateIdentity)ep.Address.Identity).Certificates[0];

Runtime Errors

  1. Unrecognized attribute ‘type’. Note that attribute names are case-sensitive.
  2. Alter your app.config file to look like this:
    <service name='X'
    Instead of this:
    <service type='X'

    (note: got this little tidbit from: Ed Pinto’s Blog )

  3. Unrecognized element ‘wsFederationBinding’
    • Change the <wsFederationBinding> opening & closing tags in App.Config to be <wsFederationHttpBinding>.
    • Change the endpoint attribute binding="wsFederationBinding" to point to wsFederationHttpBinding instead.
  4. Configuration section ‘system.serviceModel/bindings/wsFederationBinding’ could not be created. Machine.config is missing information. Please verify that this configuration section is properly registered and that you have correctly spelled the section name. For Windows Communication Foundation sections, run ServiceModelReg.exe -i to fix this error.
    • This really just means that you missed changing “wsFederationBinding” to “wsFederationHttpBinding” somewhere. You do not need to run ServiceModelReg.exe, trust me I went down that rabbit hole.
  5. Unrecognized attribute ‘defaultProtectionLevel’. Note that attribute names are case-sensitive.
    • In your App.Config, remove defaultProtectionLevel="EncryptAndSign" from
    • system.servicemodel/bindings/wsFederationHttpBinding/
      binding/security/message

    • In your C# code, add (ProtectionLevel=ProtectionLevel.Sign) as a property of ServiceContractand add (ProtectionLevel=ProtectionLevel.EncryptAndSign) as a property of OperationContract
    • Include System.Net.Security if ProtectionLevel doesn’t properly resolve.
  6. Unrecognized element ‘requiredClaimTypes’.
    • In your App.Config, replace the attributeless tag:
    • system.servicemodel/bindings/wsFederationHttpBinding/binding/ security/message/requiredClaimTypes

    • With the tag:
    • system.servicemodel/bindings/wsFederationHttpBinding/binding/ security/message/claims

    (ie <requiredClaimTypes> becomes <claims>)

  7. Unable to cast object of type ‘System.ServiceModel.DnsIdentity’ to type ‘System.ServiceModel.X509CertificateIdentity’
    • Replace a line of code like this:
    • cnFactory.Description.Behaviors.Add( (IChannelBehavior)credentials);

    • With a line of code like this:
    • cnFactory.Endpoint.Behaviors.Add( (IEndpointBehavior)credentials);

  8. X509 certificate (CN=Fabrikam) chain building failed. The revocation function was una ble to check revocation for the certificate.
    • This is the bit about revocation being set to “Online” by default. Add the following line of code (I put it right before I attach the endpoint certificate to the infocardcredentials variable (called credentials)):
    • credentials.ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.NoCheck;

    • you also need to include System.Security.Cryptography.X509Certificates for X509RevocationMode to resolve.

1 thought on “Jan/Feb CTP Deltas for Infocard

  1. Any chance of you making your code available? So far I’m finding lots of partial solutions that don’t seem to work. I am trying to set up a simple relying party system. I have three computers dedicated to this process. I have xp and two 2003 servers. The idea is that one would be the relying party, one the IP and the client. I would prefer to know how to configure the IIs server to deal with these roles. Can it be done without custom programming?

    Pam says: Hi Jay, I’m not sure that I can put the code on the internet, as it is based (if loosely after all this time) on the code from the MS Sept 2005 Resource Kit. I wouldn’t want to get letters from lawyers (-: I know exactly how you feel about the million fragments out there that all fail in some way or another — I’ve had to battle with the same problem.

    I think that you and I could work something out together. The code I have happens to combine the client and server in the same project, but that would be trivial to separate out. That code also right now doesn’t host the server on IIS, it programatically advertises the service & kicks off infocards – this is because the code predates the IE7 browser support. Fixing that would also be trivial, but of course you will have to have the code for the service itself installed. In general, what I have is pretty primitive, but it compiles & runs (which is saying a lot sadly enough) and it does at least exercise all the different entities.

    I’ll drop you a note and we can continue this conversation…

Comments are closed.