Started looking into other possible solutions and low-and-behold, the language reference actually tells you what to do.
At the bottom of the checkPolicyFile section, Adobe mentions steps to take with redirects:

1. Examine the value of LoaderInfo.url after you have received a ProgressEvent.PROGRESS or Event.COMPLETE event, which tells you the object’s final URL.
2. Call the Security.loadPolicyFile() method with a policy file URL based on the object’s final URL.
3. Poll the value of LoaderInfo.childAllowsParent until it becomes true.

I put together some example source code below to walk you through the steps.

private var loader:Loader;
private var accessChildTimer:Timer;
private var url:String;

private function init():void
{
	accessChildTimer = new Timer( 100, 100 );
	accessChildTimer.addEventListener( TimerEvent.TIMER, onAccessChildTimer );
}

public function loadImage():void
{
	loader = new Loader();
	loader.contentLoaderInfo.addEventListener( Event.COMPLETE, onLoaderComplete );

	var context:LoaderContext = new LoaderContext();
	context.checkPolicyFile = true;

	var request:URLRequest = new URLRequest( url );
	loader.load( request, context );
}

protected function onLoaderComplete( event:Event ):void
{
	var loaderInfo:LoaderInfo = loader.contentLoaderInfo;
	if( loaderInfo.childAllowsParent )
	{
		displayImage();
	}
	else if( loaderInfo.url != this.url )
	{
		var redirectURL:String = loaderInfo.url + "crossdomain.xml"; //Might want to write a method to append a '/' if necessary.
		Security.loadPolicyFile( redirectURL );
		accessChildTimer.reset();
		accessChildTimer.start();
	}
}

protected function onAccessChildTimer( event:TimerEvent ):void
{
	var loaderInfo:LoaderInfo = loader.contentLoaderInfo;
	if( loaderInfo.childAllowsParent )
	{
		accessChildTimer.stop();
		displayImage();
	}
}

private function displayImage():void
{
	//Access BitmapData here
}

Hopefully that helps you out!

At my job, I was starting to do a lot of Facebook work and was constantly seeing posts about Graph. Instead of waiting on Adobe, I started to edit their library locally to add support for Graph. I mentioned this on the issue tracker of Adobe’s library to see if anyone would be interested, and several people responded favorably… but no one from Adobe responded at all.

At first, I was pulling in the new Graph JS SDK on our site, initializing the user with it directly, and had just made a few line changes in the library to make the same old REST calls using it instead. This was just a bridge to start working with Graph. Once I had the user initialized with it, I was able to start taking advantage of the new calls. I then started making more changes, next supporting the JS SDK’s UI methods and then the actual API. After a few months of writing and working with the library in a production environment, I decided to upload my branch of the library to GitHub.

I did this at the beginning of September. Between May and September, several people were complaining about the complete lack of support of the official Adobe library with no response at all. In fact, Jason Crist the original author of the library who handed over control to Adobe was getting frustrated with the lack of support as well and reached out to me about joining forces on the new library. But within a week of just talking about it, Adobe comes out of the blue and says that a new library with Graph support was coming. They were obviously working on it for a while, because the day after they announced that, it was uploaded. Thanks for the head’s up Adobe!

So if you’re keeping tabs, the officially supported library didn’t see an update from December 1, 2009 through September 30, 2010. That’s almost 10 months. So you’ll forgive me if I didn’t believe this new library would be supported any better. I did however like what they had done with the library, most of it that is. I decided to rewrite my library again, but this time based on the new Adobe library. I continued to maintain my branch for several reasons: support being the biggest, a few issues I was noticing with the new library, and lack of typed value objects for the returned data.

As I find issues with the core library, I update them in my branch. Most of these changes in turn get implemented into the core library. In fact, I was annoyed that the new library required an external JS file and a special way of embedding the swf, so I rewrote the JS in an ActionScript class that gets injected into the HTML at runtime, and Adobe now uses that class directly with no modification. I reached out to Adobe to see if I could become a committer on the library, they responded, but unfortunately didn’t seem too interested. So instead I continue to maintain my branch.

Long story short, if you’re using the officially supported AS3 Facebook library, you might want to check out my branch too. You might just find that your issues and suggestions get taken into account faster, if Adobe does make any updates to their library, I make those updates as soon as I notice, and you might like having typed objects for the returned data (like FacebookUser instead of just a generic object with the user’s info).

Get it here: https://github.com/yourpalmark/facebook-actionscript-api
Docs: http://yourpalmark.github.com/facebook-actionscript-api/docs/

I also maintain an AIR branch as well: https://github.com/yourpalmark/facebook-air-api
Docs: http://yourpalmark.github.com/facebook-air-api/docs/