We don’t have a Ping Federate server that processes openid connect flows – but Ping Identity did give use the clients that exercise (those endpoints). Lets see what happens when we use our own AS/STS, that delegates to Azure ACS, as the endpoints. Perhaps we can learn more about what is driving openid connect.
Unlike Ping Federate, our own Authorization service is multi-tenant (each tenant being supported by a custom SQL db, membership provider and unique ACS namespace). So we connect the client to one such tenant:-
What this does is require us to have registered the special scope “openid”. So lets add that:
The pass through rule connects the scope(s) to the issuer that tags valid delegations of authority
We firm off the Ping Federate form that attempts to land on our consent page – guarded by Google webSSO. As usual, this page takes the claims from Google and writes a delegation record to the ACS namespace, before redirecting to the (ping federate) form registered as the redirect URI tied of the service principal of this “client”. Presumably, when using a Ping Federate AS for openid connect flows, it notes the scope “openid” and does “special things” – behind the scenes. One day, we will find out what they are!
The request and response look pretty normal (except for the additional fields…that enable the client to instruct how the websso is to happen or be processed upon result, presumably).
After some fiddling (and some bug fixing), we get an openid-connect specific followup”
ok. so we have learned a little (which is slightly more than the zero we knew yesterday); and also learned that ACS token issuing point will not accept a scope of “openid” (though urn:openid is fine); and also learned how to mint a symmetrically-mac’ed JWT. We also see what is supposed to have next…. in the openid connect world (get user info);
For now, our result! Of course, a real Ping Federate server would work (unlike our simulator)