Almost getting to a ADAL login view for IOS controlling access to an Sp-initiated websso site.


The demo IOS application using the Microsoft Open Source IOS ADAL library does the following – when talking to an IDP behind the microsoftonline FP:

image

image

giving

WIN_20140612_100613

 

We see the FP stack its request and request upstream to our IDP – where we see the response-address (for the now the stacked request) stored  deep within the wctx stack. Note that the IDP has “to know” the response address to its own request, to be inferred from the wtrealm value.

image

image

Above, we see an assertion being delivered to the FP, issued by the IDP in the name of UPN=andy@rapmlsqa.com. This maps to an account in AAD allowing the FP to assert to the AAD waiting ACS endpoint – that duly authenticated the user and allows the AAD AD to mint an authorization code that is delivered to the phone app:

image

which turns around and converts the code into a token set:

image

now, our IDP itself used an STS, communicating with it using the ws-trust v1.3 protocol. This confirmed the challenge parameters (of andy/1234). the WS-fedP IDP itself minted a local session and forms auth cookie in the name of rapbroker (per the configuration of the IDP):

image

So, all in all, the phone called our IDP using the URI;

https://ssoportal.rapmlsqa.com/spinitiatedssohandler.aspx/bars/8?username=andy%40rapmlsqa.com&wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26wtrealm%3Dhttps%253a%252f%252flogin.windows.net%252f%26wreply%3Dhttps%253a%252f%252flogin.windows.net%252fcommon%252fwsfederation%26wctx%3D3wEBD09BdXRoMkF1dGhvcml6ZQEPT0F1dGgyQXV0aG9yaXplAAEBAQ9vYXV0aDIuYXV0aGNvZGUAASRodHRwczovL3JhcG1sc3FhLmNvbS9Ub2RvTGlzdFNlcnZpY2UBASRhNmU0ZWU2My04N2YzLTQ1YWYtYTVkYi0wNTA5OWFiOWYwMDEBFWh0dHA6Ly9Ub2RvTGlzdENsaWVudAABAQERY2xpZW50cmVkaXJlY3R1cmkBFWh0dHA6Ly9Ub2RvTGlzdENsaWVudAEGAQVzdGF0ZQF3WVQxb2RIUndjeVV6UVNVeVJpVXlSbXh2WjJsdUxuZHBibVJ2ZDNNdWJtVjBKVEpHWTI5dGJXOXVKbkk5YUhSMGNITWxNMEVsTWtZbE1rWnlZWEJ0YkhOeFlTNWpiMjBsTWtaVWIyUnZUR2x6ZEZObGNuWnBZMlUBD2xpbWl0X3Rva2Vuc2l6ZQEEVHJ1ZQELaW50ZXJhY3RpdmUBBFRydWUBCUxvZ2luSGludAERYW5keUByYXBtbHNxYS5jb20BD0ZvcmNlRnJlc2hMb2dpbgEFRmFsc2UBA3NpZAEkYmE0ZjYxMGUtYjcxMy00ZDRiLTgwMzctNmVlMjM0OTA0MjZl7Q2%26wp%3DMBI_FED_SSL%26id%3D

if a webview on the phone now navigates to

https://ssoportal.rapmlsqa.com/SPInitiatedSSOHandler.aspx/BARS/6?wa=wsignin1.0&wtrealm=http://tablet.com/&wreply=http%3A%2F%2Fm.rapmlsqa.com%2FSPHandler.aspx%3FMls%3DBARS

 

we see this request to the same IDP (acting upon the forms auth cookie, now) we see the IDP mint an assertion now in the name of the (then current) session holder and targeting the SP site that is NOT governed by the AAD regime (or US export rules, as projected globally by Microsoft)

image

Or we WOULD were it not for the fact that the login view in the ADAL IOS toolkit is unlike the MSLogin code in the azure mobile toolkit. The latter preserves cookies between calls to the login process (and to web views). The ADAL toolkit does not (since cookies and the like are not controlling the lifecycle of token refreshes). So lets figure how to injhect cookies obtained via the webview launched in the ADAL library into the webview to which we redirect our app, post login and token collection.

We are not USING our token (for anything other than controlling the UI for login prompting, logout prompting, expiry handling).

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in AAD. Bookmark the permalink.