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?
Edited byReggie ChenMonday, April 09, 2012 4:00 PMBetter wording
STS would strip off the security token within an iframe? Which STS? facebook or ACS? When the iframe app is loaded and it invokes the "login URL" of facebook from the downloaded HRD json feed,
I can set upa break point at the ASP.NET MVC code being visited by subsequent POST from ACS, I can inspect the claims correctly. It goes wrong when Silverlight client calls the authentication service provided by WIF SL.IdentityModel.Server.dll.
Somewhere down the pipeline of my web application strips off the token? Can you explain me a bit in detail, or provide me a link to study?
I am not sure how to pursue Active Federation with WS-Trust for a public identity provider like facebook. Is it possible? According to Microsoft, SL5 supports WS-Trust for in-browser situation,
but I did not see any example posted in the net.
How about relaying claims through the new ASP.NET web api like Dominick Baier’s https://github.com/thinktecture/Thinktecture.IdentityModel.Http? Would making claims available via “value controller” creating different result than SL.IdentityModel.Server.dll?
Aren’t they all REST services? My last line of defense is to relay the claims encrypted with a shared key as a runtime parameter passing to the Silverlight client….