Ping Federate (modern) imports the metadata, producing the local configuration as shown above.
For Microsoft engineering (doing final debugging). this was the result:
Well, obviously I’m missing the step of importing the IDPSSO descriptor listed by the SP, into Azure AD.
So how do I do that?
well lets configure PingFederate SP to both be named as an entity using a http URI in the validated namespace and also listen on an endpoint in the same. Also, we logically add an SP record to the IDP authorizing information flow via assertion:
The result is slightly better than before:
Lets now simplify, and ensure we are using a managed account, first. With it we can with our existing setup get a SAMLP response:
So, lets now change the name/address of the APP and make it the ACS endpoint of the SAML SP server awaiting the response:
We get at least the processing of the response, now!
Clearly ,we can now process the result, but it violates an SP policy. We see a missing subject name in the authentication statement (which probably upsets the traditionalists):
We can extend the time period allows by PingFederate (globally), thus:
Suggests Ping Identity needs to make the time allowance configurable by IDP CONNECTION – not that my opinion is probably of any consequence.
This allows a first end-end trial:
Some Request options cause the Azure Endpoints to crash (e.g. force authn)
Also, since Aure AD is using RSA with SHA256 I wonder if it will work with our 2 year old SAML server (that may not support that ciphersuite)?