9. dubna 2012 8:15
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?
9. dubna 2012 19:06
It could be that the service is stripping out the token because it's within an iframe. Quite a few STS will do that to protect the token. You may have to go an active route to get the token.
Developer Security MVP | www.syfuhs.net
9. dubna 2012 22:50
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 up a 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….
10. dubna 2012 14:54Moderátor
As pointed out by Steve, many STS will reject our requests if they come from iframe. As a test, we can try to embed an iframe that requires sign in in a local html page. Something like:
When we run the page, we will see the content in the iframe will not be rendered, and an error message is displayed indicating “This content cannot be displayed in a frame”.
I am not familiar with Facebook canvas. Dose is require iframe? Since your app is hosted in Facebook, it would be better if you can obtain the user’s Facebook consent directly.
- Označen jako odpověď Arwind - MSFTModerator 16. dubna 2012 8:34