Jim Rogers

Lives in Baton Rouge, LA, with two dogs, one cat, and one lovely wife. I'm a lead developer for GCR Incorporated.

Katrin and Jim

Month List

No claim is generated in policy engine

by Jim Jan 24, 2011 8:12 AM

In setting up my azure web role for use with Access Control Services, I get this error, which doesn’t turn up anything in the search engines.

s5t4uq3o

My interpretation of this is that ACS doesn’t have sufficient information to create claims from the identity provider(s).

I solved this problem by configuring rule groups for my relying party. In the AppFabric labs portal, choose ‘Relying party applications.’

buw5txhf

I’ve set up my local machine as a relying party for testing locally, so I choose this, then check the ‘Create new rule group’ box, and click save:

d0nx02v0

I’m bounced back to the list of relying party applications; choose the application again, then click the new ‘Default rule group for…’ link:

image

There are no rules defined for this new group. Click ‘Generate rules,’ then click the ‘Generate’ button to create rules for all identity providers. You should now see a big list of generated rules, and the ‘No claim is generated in policy engine’ should go away. On to the next error!

image

Tags:

Code

Parse a little-endian

by jim Jan 01, 2011 3:44 PM
littleindian

What? No, e-n-d-i-a-n. In the computer world, it’s not unusual to find integers represented in reverse byte order, with the least significant digit first. For example, the hex representation FF01 might be two very different numbers, depending on whether it is big-endian (the way we’re used to seeing them in base 10):

base 16:            FF    01
base 10:           255   001
times position:    2^8   2^0
add to get int:  65280 +   1  =  65281

or little-endian:

base 16:            FF    01
base 10:           255   001
times position:    2^0   2^8
add to get int:    255 + 256  =  511

The javascript parseInt() method assumes a big-endian representation in the string passed to it. Here’s a method that parses a little-endian hex string.

function parseLittleEndian(hex) {
    var result = 0;
    var pow = 0;
    while (hex.length > 0) {
        result += parseInt(hex.substring(0, 2), 16) * Math.pow(2, pow);
        hex = hex.substring(2, hex.length);
        pow += 8;
    }
    return result;
};

Troubleshooting Azure issues

by jim Dec 20, 2010 12:00 PM

This post is a bucket for various issues I’ve run across getting my Azure application working and authentication hooked up. With this new technology, solutions can sometimes be hard to come by.

CommunicationObjectFaultedException

I’ve gotten this exception trying to debug my web role, on more than one occasion.

There are a few causes of this exception documented online, but I’ve found that it can be caused by the general case of any failure to validate the web.config file. For instance, an invalid tag or attribute value can trigger this. 

<foo></foo>

or this empty path value in the location tag:

<location path="">
System.ServiceModel.CommunicationObjectFaultedException was unhandled
  Message=The communication object, System.ServiceModel.Channels.ServiceChannel, 
    cannot be used for communication because it is in the Faulted state.
  Source=mscorlib
  StackTrace:
    Server stack trace: 
       at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
       at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
       at Microsoft.WindowsAzure.Hosts.WaIISHost.Program.Main(String[] args)

AudienceUriValidationFailedException

ID1038: The AudienceRestrictionCondition was not valid because the specified Audience is not present in AudienceUris.

Audience: 'https://127.0.0.1:444/'

Exception Details: Microsoft.IdentityModel.Tokens.AudienceUriValidationFailedException: ID1038: The AudienceRestrictionCondition was not valid because the specified Audience is not present in AudienceUris.

This means that the WIF configuration doesn’t list the return address as a valid ‘audience uri.’ In your web.config, add the desired address (the one in the message) to the list:

<microsoft.identityModel>
  <service>
    <audienceUris>
      <add value="https://127.0.0.1:8080/" />
      <add value="https://127.0.0.1:444/" />
      <add value="https://casestudy.cloudapp.net/" />
    </audienceUris>

You can have more than one value in here, but I suppose the most secure solution for a production deployment is to limit the list to the necessary value(s).

Another solution is to turn off the check altogether:

<audienceUris mode="Never">

But wait, what about a staging deployment? We don’t know the URL until we’ve deployed, and at that point we can't enter the value in our web.config!

Am I doing this wrong? Do the MS example and see if it works in staging with ACS and the guid address.

No response at all?

imageimageAre you using certificates? If the configuration of the cert or endpoint is set up wrong, you may get a generic “Internet Explorer cannot display the webpage” error.

  On the other hand, if there is no http endpoint configured and you try to access the site with http, you’ll get a “web server refused the connection, ” “10061: Connection refused.”

In the latter case, it’s probably best to configure the http endpoint and have a default, unencrypted landing page, if you’ve got a public site.

The certificate name doesn’t matter in the configuration files, as long as it’s the same in the various places where it’s referenced in configuration. In the service definition file, it should look like this:

<Certificates>
  <Certificate name="MySSLCert" storeLocation="LocalMachine" storeName="My" />
</Certificates>

The store location is important! However the cert is found not by name but by thumbprint; this is specified in the service configuration file:

<Certificates>
  <Certificate 
    name="MySSLCert" 
    thumbprint="4653AE813BA15DFFB027E3AC147004B2D24F472B" 
    thumbprintAlgorithm="sha1" />
</Certificates>

The certificate name is also referenced in the https endpoint configuration.

Issuer of the security token was not recognized

I got this error coming back from authentication, when the browser was redirected to my site.

ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer

This means your application is checking the token to ensure that it came from a preconfigured provider, and it can’t find a match. Here’s the relevant section of the web.config file:

<issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuer…">
  <trustedIssuers>
    <add thumbprint="5F7F612950EB8F17FD102F8579EE409C1B81BC5B" 
         name="https://JimACS.accesscontrol.appfabriclabs.com/" />
  </trustedIssuers>
</issuerNameRegistry>

In my case, the AppFabric labs were updated and the certificate thumbprint changed. I couldn’t find a way to obtain the current thumbprint through the ACS management portal.

Warning: this is gonna reset other things in your web.config file, so make sure you’ve got a backup to compare to.

Go through the ‘Add STS Reference’ steps again, with whatever options you used before. This will add an additional trusted issuer to the list in the web.config file, with the correct thumbprint.

NullReferenceException

A common bit of code found in the Azure sample is this block, which switches the cookie encryption to a RSA for compatibility with a web farm (multiple IIS instances.)

List<CookieTransform> sessionTransforms = new
    List<CookieTransform>(new CookieTransform[] { new DeflateCookieTransform(),
    new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate)
    });
var sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());

e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);

There’s no check to see if the service certificate is configured, which can be done in the web.config file:

      <serviceCertificate>
        <certificateReference x509FindType="FindByThumbprint" findValue="4653AE813B..." />
      </serviceCertificate>

I’ve put the following block of code above the encryption code to give me a meaningful message if the certificate configuration is gone – for instance when rebuilding the ACS connection with the solution explorer’s ‘Add STS Reference’ wizard.

if (e.ServiceConfiguration.ServiceCertificate == null)
{
    throw new ApplicationException("No site certificate; is it set up in web.config?");
    // Make sure you've got the service certificate set up in the web.config:
    // <serviceCertificate>
    //   <certificateReference x509FindType="FindByThumbprint" findValue="4653AE813BA15DFFB027E3AC147004B2D24F472B" />
    // </serviceCertificate>
}

References

Common Windows Identity Foundation WS-Federation Exceptions Explained

Tags:

Code

Diagnosing role startup issues

by jim Dec 10, 2010 2:18 PM

There are a lot of reasons why an Azure role may fail to start, and it’s not easy to figure out what the problem is. Since the role hasn’t started there is no diagnostic information to see. The portal just infinitely cycles through states of initializing, busy, and aborted.

0aw1bz2d

image

There is information about potential causes of these issues here and here.

I’ve been bitten by this when using MVC3 and other third-party assemblies; a failure to include these in the install package might be the most likely cause of a failure during role initialization (as opposed to difficulty at the IIS level, which usually manifests as an error message when accessing the site.) The solution in this case is to set ‘Copy Local’ to true for any assemblies you reference that aren’t part of the default .NET framework installation.

If you’ve got the money to drop on Visual Studio 2010 Ultimate, then you can use intellitrace to debug startup issues.

Without intellitrace or other diagnostic information, we’re left blindly going through the list of potential problems and attempting deployments until we get our role to start. My suggestion is to deploy to staging on a regular basis, and after any structural, service, or dependency changes to the application, in order to limit the number of changes that might have caused a problem.

Tags:

Code

MVC3 in Azure

by Jim Dec 03, 2010 1:19 PM

The Azure SDK and tools haven’t caught up with the MVC3 release candidate yet, but MVC3 is compatible with Azure. Here’s how to get a basic MVC3 web role up and running in the cloud.

I’ve got the Azure SDK and tools version 1.3 installed, and of course the MVC3 release candidate.

Open Visual Studio 2010 and create a new project and solution, choosing the Windows Azure Project. Choose the MVC2 web role:

fwrlcckf

Now add a new project to your solution; this is a temporary project for copying settings and whatnot.

k4u53sry

For the project template, I’ve chosen “internet application” with the razor view engine.

Now for the conversion – first we delete the System.Web.Mvc reference from our MVC2 web role and reference the MVC3 assembly instead.

The default MVC3 application also references System.Web.Helpers, which isn’t in the MVC2 app. Add that reference.

The web.config files have a number of differences; just copy the contents of the v3 file over the v2 file.

Delete the temporary MVC3 web project, leaving only the original web role.

At this point you can hit F5 and run locally. The account pages won’t work, because you’re pointed to a SQL Express database, but that’s outside the scope of this demo :-)

Now go to the fancy new Silverlight portal and add a hosted service account, with a corresponding storage account (which we just need for our logging right now.) Click the “view” button next to the primary access key and copy it to the clipboard.

image

The service definition and service configuration files have changed a bit in the 1.3 SDK, with regard to diagnostics, but the diagnostics connection string value works as before. Update the AccountName and AccountKey values.

<ConfigurationSettings>
<!--
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
value="UseDevelopmentStorage=true" />
-->
<
Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=mvc3demo;AccountKey=[your key]" />
</
ConfigurationSettings>

We’re almost ready. The MVC3 release won’t be installed in our Azure instance, so we’ll need to ensure that these (and any other third-party assemblies you might be using) are copied locally, and get uploaded as part of our install package. The assemblies in question are:

  • System.Web.MVC
  • System.Web.Helpers
  • System.Web.WebPages
  • System.Web.WebPages.Razor
  • Microsoft.Web.Infrastructure

These last three aren’t in the reference list by default, so you’ll need to add them. They will be loaded dynamically when a page is requested (WebPages is in the <compilation> section of the web.config file.) Right click on each assembly reference in solution explorer, view the properties, and change “copy local” to true.

Now we can deploy to the cloud!

loavpftn