Microsoft Dynamics CRM Online with a Windows Azure Hosted Webpage + IFrame + X-Frame-Options

5
votes

I am trying to use Microsoft Dynamics CRM Online where Windows Azure hosts a custom webpage that is displayed in an IFRAME of the Microsoft Dynamics CRM web application.

I have read http://msdn.microsoft.com/en-us/library/gg509061 (Microsoft Dynamics CRM Online with a Windows Azure Hosted Webpage) and also followed the instructions on http://social.technet.microsoft.com/wiki/contents/articles/2590.aspx (Secure Windows Azure Web Role ASP.NET Web Application Using Access Control Service v2.0)

I now have a Windows Azure Webpage that displays a Windows Live Id screen to log in.

The problem is that when I place this into an IFrame in Dynamics, I get the following:

This content cannot be displayed in a frame To help protect the security of information you enter into this website, the publisher of this content does not allow it to be displayed in a frame.

This is due to the HTTP header of "X-Frame-Options:deny" served by the Windows Live Id login preventing Internet Explorer from displaying the page in a frame. This even happens when I am already logged into Windows Live Id and the webpage tries to authenticate me.

So how is this meant to work, as the first Microsoft page implies it can be done with "Microsoft Dynamics CRM Online with a Windows Azure Hosted Webpage" and optionally displayed in an IFRAME?

1
iframeazuredynamics-crm-2011access-controlx-frame-options
I could be way off the mark, but I wonder do you need to use Windows Azure Access Control Service for Federate Claims Based Identity on the Web Site you are using to circumvent this, basically have your Web Site act as a relying party for Live Id Identity provider via ACS. When the user hist your webpage in the IFRAME they get redirected to Live ID, login in, claim based token is passed back which is accepted by Dynamic Online? This might be overkill mind you, just a thought. I haven't tested it, am sure there is an easier solution mind you :) – user728584
Did you get this to work? – Stefan
@Stefan - No, I did not get it going. – Monkey Code

1 Answers

0
votes

This post suggests a workaround implemented by opening the sign-in page in a new window. That can be accomplished through standard window.open(...), but if your users are going to use the Outlook client, you'll have to jump through some extra hoops since the embedded browser does not share session data with the user's default browser. (A workaround for that is to use Xrm.Utility.openWebResource(...) instead, with a custom HTML page that redirects to the intended page.)