As in discussion at
http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/fb1a021d-60fc-4bdf-b2be-be733e67991c , I am creating a
facebook canvas application
that also runs as a relying party of ACS, and this canvas application is a
silverlight in-browser application
utilizing SL.IdentityModel.dll and the authentication service of SL.IdentityModel.Server.dll to access ACS claims . My test application is basically copied from the Silverlight passive case in WIF training kit with modified STS endpoint replaced
with my Azure ACS namespace url.
The app is built with Silverlight 5 and ASP.NET MVC. The plan is the same Silverlight application
will run in both scenarios: either as an in-browser application from our server like in the example of training kit or runs in facebook via hyper link such as apps.facebook.com/mysilvelrightapp as an HTML iframe application ( facebook will redirect to
www.myserver.com/mycontroller/ according to my facebook app registry ).
When launching the app from my website as a normal in-browser Silverlight application, everything runs fine with correct
claims return from ACS upon successful authentication with SL.IdentityModel.Server.dll.
The problem occurred when it runs as an iFrame application under facebook! It could not find any claims. The identity under HttpContext.Current.User is always null in this scenario!
Here is my basic control flow under facebook. Upon requesting my canvas app, the user will get authenticated in facebook
first. My web application will then download the identity providers HRD json feed from ACS, and retrieve the facebook login url and set it as windows.top. Because the user has already been authenticated, ACS won't prompt for user credential and will just POST
to the web server with WSFederation replyto, which happens to be the url that hosts my Silverlight application. What puzzles me is before entering Silverlight application, when ACS post return URL to my Silverlight Controller, the HttpContext.User.Identity
is good, and I can inspect all the correct claims there returned from ACS in debug, but once the flow transfer to Silverlight, to the
ClaimsIdentitymanager, it cannot find any claims! The authentication service of SL.Identitymodel.Server at the server side comes back with HttpContext.Current.User is not authenticated! In other word, the authentication web service call result
from the Silverlight client is different than the earlier POST issued from ACS!
What went wrong? The behaviors of the two scenarios (running on my site and running as a facebook canvas ) are the same up until Silverlight taking over control
and invoking the authentication service! Aren’t Silverlight client and the controller in MVC sharing the same session? It is not the case if the client app is running under an iframe?