Having used the STS wizard in the project template to create a working webapp (bound to an Azure AD instance that can administer trust graphs – or links to other IDP), we ran our webapp and tried to use its signin button. The result was as follows:
One might be tempted to go into the web.config and add as a trusted issuer the appropriate IDP. AS one does so, one notices that the issuer registery is no longer a simple list (of statically configured trust points in the directory). Now, the register uses a web-app-stored db of such IDPs, to be updated as administrators use the “sign up for this application” button.
Let’s assume that the failure to do user signin is due to the IDP-administrator of said user not yet having “signed up to the application” (and thereby not have yet induced his IDP to be added to the trust graphs of this webapp). Let assume this means that there are missing entries in the graph of the webapps management point IDP … for this IDP. And perhaps, there are missing entries in the webapps own list of trustpoints (the cert hashes).
So lets add a new IDP to this webapp’s management-point IDP’s trust graph. What we see is an oauth handshake, invoking a consent dialog amid the sign’up process.
I, the administrator of some third-party IDP wanting to grant the webapp the right to consume the assertions my IDP mints, do consent (via oauth processes) to being added to the webapps trust graphs(as managed by its own management-points IDP). Of course, I had to authenticate before consent would display (using a websso process, involving my own organizational IDP).
The resulting blurb suggests that I have the model the inside out:
This suggests that it’s the graph of the JOINING IDP that stores whether or not it will “release” assertions to this webapp. The process has provisioned a “pro forma” application in my list of authorized RP.
The basic sequence of the consent phase of oauth authorization, supported by websso, seems to show below:
So how should we characterize what we are seeing?
I suspect its Not appropriate to see this use of oauth as used classically (to authorize a third party site to populate material in an embedded view page). Nor is it applicable to the more recent “enabling” of apps on devices, or those apps’ access to APIs. It is a re-purposing of OAUTH to control the sharing or federation metadata – for RP signup. Its how one dynamically adds an RP trust to ADFS (conceptually).
When we look at the local database of trust points (for use in validation of assertions), we see:
now we can signin…
In the session capture, we see 3 nestings of websso:
We can look at the new one (red/common) as IDP discovery.