locked
WinJS pattern for dealing with pop-up window communication

    Question

  • As an SPA, our web application implements federated identity using pop-up (browser) windows with the following pattern

    • Main site page (e.g. www.site.net) never leaves index.html
    • When needed to authenticate with a 3rd-party identity provider (e.g. Facebook, Twitter), main page pops up extra window with window.open() directing to our federated identity service (e.g. fed.site.net)
    • Request lands on federated web server, determines which identity provider it is for, and makes regular HTTP redirect to said identity provider OAuth URL.
    • After authentication and authorisation with identity provider, pop-up window gets redirected back to federated server with OAuth results.
    • Federated web server passes OAuth results (if success) to backend to perform OAuth identity check to authenticate 3rd-party user and match up with our own identity store.
    • Backend responses with our own user identity credentials, which federated server further packs as encoded query string in a redirected URL back to main site (e.g. www.site.net/auth.html?xxxxxx) Note that this is still the pop-up window.
    • Now that redirected page origin is the same as the main page window (i.e. www.site.net), the results can be handed back to main page app via window.opener.authCallback().
    • Main page app receives the authentication results and credentials and proceeds thereon.

    As you can see this federated identity pattern is heavily dependent on the working mechanics of existing browsers and web servers.

    Now we'd want to see what happens when we convert the existing web app into a Windows Store WinJS app. Due to the complexity of our Javascript implementation and WinJS operating model restrictions, we run our app in Web context to ensure maximum compatibility.

    All the local context default.html has are

    <!DOCTYPE html>
    <html style="width:100%;height:100%">
      <body style="width:100%;height:100%;border:0 none;margin: 0;padding: 0;overflow:hidden">	
        <iframe style="width:100%;height:100%;border:0 none;margin: 0;padding: 0;overflow:hidden" src="ms-appx-web:///index.html">
        </iframe>
      </body>
    </html>

    Most things seem to work great this way. Except for the above authentication workflow.

    The pop-up window happens in an external web browser, and of course, this causes a complete disconnect; there is no way for the pop-up window to ever communicate back to window.opener since they are completely two separate processes.

    What is the recommended practice to make this work in the operating context of WinJS apps?


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral




    • Edited by icelava Monday, October 27, 2014 4:44 AM formatting
    Monday, October 27, 2014 4:32 AM

Answers

All replies

  • Have you looked into using Web Authentication broker? http://msdn.microsoft.com/en-us/library/windows/apps/dn448955.aspx

    The complete sample is shared here: https://code.msdn.microsoft.com/windowsapps/Web-Authentication-d0485122 you can check it and see if it fits your needs.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Monday, October 27, 2014 5:47 PM
    Moderator
  • I did look at Web Authentication Broker (WAB) but my understanding is incomplete. If I understood (so far) what I have read about it properly, what the client needs to do

    • instead of directly making window.open() straight to https://fed.site.net/authrequest/facebook, it needs to post that URL as a message to the Local context page (default.html).
    • it is the Local context app Javascript that would then invoke a sequence for WAB so it would open its separate web host window like a modal dialog over the main app screen; thus serving as the "pop-up browser window".
    • The WAB's window would then browse to the fed web server and get redirected to 3rd-party identity provider as per normal.
    • The 3rd-party provider would then also redirect the WAB window back to fed server (e.g. /authcallback/facebook) as per normal.

    What happens here on is a question.

    In the regular web browser workflow, auth server would redirect once more to www.site.net/auth.html?xxxxx with our own proprietary custom data set, the page which would feed the data back to main window page via window.opener. (Since they are now the same origin)

    What exactly does WAB expect at the "end game" page (end URI to terminate workflow and start looking for some data) is not described comprehensively. If we knew exactly what data it seeks out, then it may be possible to feed that to WAB which in turn feeds back to the Local context app, which can then post the result data into the Web context iframe where our client app lives.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Tuesday, October 28, 2014 12:17 AM
  • Have you looked at the single sign-on functionality described in the MSDN link above? Once you associate your app with the Store, you will receive a unique SID value in the form of ms-app://s-1-5.... which you can use as the "end game" URI that the Web Authentication broker expects. This ms-app SID is where the Web Authentication broker will post the data back to the app.

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Tuesday, October 28, 2014 12:41 AM
    Moderator
  • Prashant, that does not answer my question: what exactly is WAB looking for in the end game final results page?

    application/xml document? application/json object? plain HTML? Object structure/hierarchy? What properties and values in the data?

    We cannot use the SSO mechanism for a couple of reasons

    • When the redirect from the 3rd-party identity provider comes back, it passes data back to our federated web server as query strings. Depending on which provider, the query string parameters differ.
    • The return parameters include an OAuth token which we use to interact with said identity provider in the backend to actually discover which 3rd-party user this is.
    • Some providers' OAuth implementation require the generation of additional server-side (our side) temp token to match the request token, which we pass to the client as a cookie so when they return back to our side, we can read that cookie's temp token to complete the OAuth interaction with said identity provider.
    • Once we know the identity of 3rd-party user, the backend tries to match that against our own internal user base. If a user is not found, a new user account is created, otherwise the existing user is retrieve and a new access token is assigned for this authentication sequence. This set of proprietary data is handed to the federated web server, which is encoded as query string in another redirect back to main site end result page (where it can inject the data into main window page since they are same origin).

    I am highly certain WAB is not expecting our custom set of data, and wants to look for something else in a page or whatever HTTP response. The exact set of specifications of what it is looking for is what I am interested in.


    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Tuesday, October 28, 2014 2:39 AM
  • So, if I understand your question correctly, you want to know that once you call the WebAuthenticationBroker.AuthenticateAsync function from your app, which brings up the authentication broker popup window...the WAB does all the necessary redirects with your server, and in the end...you want to know what is the format of the HTTP response that the WAB expects so that it can correctly populate the WebAuthenticationResult return value, is that correct?

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Tuesday, October 28, 2014 10:56 PM
    Moderator
  • you want to know what is the format of the HTTP response that the WAB expects so that it can correctly populate the WebAuthenticationResult return value, is that correct?
    Yes, is there any documentation on that?

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Wednesday, October 29, 2014 2:01 PM
  • The Web Authentication broker tries deviate from IE to a very little extent, so it should be possible for the WAB to just consume the same response to what you have in your existing Web logic. As such, there is no specific documentation or format requirements other than what is already documented.

    If you run into any specific issues, please take a look at troubleshooting the WAB using this link: http://msdn.microsoft.com/en-us/library/windows/desktop/jj658959.aspx & http://msdn.microsoft.com/en-us/library/windows/desktop/jj658958(v=vs.85).aspx and then we can understand if any changes are required to be made.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Wednesday, October 29, 2014 6:08 PM
    Moderator