By default, Azure STS do not come with metadata pointing at openlink’s openid endpoint.
To make a realty site talk to the openlink’s openid auth endpoint as an IDP (and as an authentication authority to a downstream IDP bridge) make the Azure bridge discover the new OP. To do this, it must read the XRDS file. We learn the location of the file by simply looking at the metadata for a particular openid identifier:
For this user (and probably all others), the XRDS is at http://id.myopenlink.net/openid-proxy/id.vsp?xrds. It is pretty simple, and unlike the HTML metadata is not specific to a given user.
note how the type is http://specs.openid.net/auth/2.0/signon
Should it be http://specs.openid.net/auth/2.0/server ?
Let’s now try to use the XRDS locator in a formal discovery process:
We see that, given an openid identifier, the code finds the relocator:
We then see the client reading the XML stream, and parsing it (rather manually):
However, the code is structured to test the metadata for v2:
Thus the discovery fails, since v2 is required (and the site does not claim to be v2).
Let’s try to fix it by assuming its v2 (and assume there was just a typo in the XRD):
This allows to get to:
Stands a change of working, end to end, now! Now, I bind to to an account linking server (classical SAML1) which pops up the local logon challenge of the IDP bridge, before tying the name claim to the local account on the bridge.
To map the name all the way through the STS we do:
The net result is:
and then
and then
and then another easy fix for issues on the return leg:
Well done Kingsley (and openlink team).
