Though it eventually worked (again), we had problems at the protocol level with the demo XAML-based windows store app talking to office 365 APIs.
This is a scenario in which the XAML page loads an standard authenticator class from the office 365 names space – that formulates up an ADAL request pre-set to use the correct “and magical” redirect value. This is the value that induces the WAB to maintain values in its cookie jar, after its used – so that they can be be on a subsequent interaction with IDPs, FPs, and the like.
The flow for a web app doing largely the same thing is as below:
The problems seem to have been in how the microsoft online FP works, when despite having requested a username of say support170 the stored credentials wizard of the WAB would pre-populate our form with its preferred credential set. The response would come back, entirely conforming, but the FP would somehow decide that the “user had abandoned” the flow – presumably by NOT sending back the support170 identity selected at the FP.
So we have a twist, in which the cookie container for the WAB, now able to store the UPN selected by the user on a previous round, auto-populated this value in the request to the FP. The latter then signaled (the same) to the IDP, whose WAB=based viewer then decided to show a previously stored auto-form-populating value in the page of the IDP – which was NOT aligned with the FP signaled value. Since the user did not KNOW which current “stay signed in” was in charge of the FP, the resulting assertion from the IDP did not align with its expectations – and induced a FP- flaw – that showed up in the UI as user abandoned the flow (not that this is really true).
It was fixed when I happened to (a) used the app’s signout button (which CAN now update some cookies in the FP site and the associated WAB store, and (b) figure that user credentials on the PC in question should be removed for the IDP’s URI, for the “hidden” user identity.