As an experiment


as an experiment, we configured an older version of ping federate to act as a SAML2-P SP and configured its “IDP connection” to talk to the SAML2 endpoint in our Active Directory tenant, intending that said service do protocol conversion and initiate a ws-fedp request through the usual chain of ws-fedp IDPs targeting our own AAD custom domain IDP.

http://netmsso.rapmlsqa.com/sp/startSSO.ping?PartnerIdpId=https://sts.windows.net/bcbf53cf-af9a-4584-b4c9-6d8b01b3781d/

(not public)

 

image

We see the initiating URI on Ping Federate send off a SAML request, at 1

At 2, the inbound request is stacked. A ws-fedp request is issued to login.windows.net (which I think of as our AAD)

At 3, that request is also stacked, and another ws-fedp request is issued to login.microsoftonline.com (to do organizational ID discovery, on behalf of our office 365 tenant).

At 4, after discovery the IDP endpoint of the organizational ID domain is located – which is logically ADFS. It actually lands on our multi-tenant realty IDP.

At 5, we see the authenticating IDP’s response (after users pass challenges etc) targeting Microsoft Online’s endpoint.

At 6, we see the MicrosoftOnline (office365…tenant) relaying/reissuing its inbound response, targeting login.windows.net (AAD tenant).

At this point in the response relaying process, we get an error – that basically says that the AAD instance does not know the saml2 entityID:

https://login.windows.net/bcbf53cf-af9a-4584-b4c9-6d8b01b3781d/wsfed

image

Additional technical information:

Trace ID: 7b15d695-123f-4c9c-938e-a400d1e8c692

Timestamp: 2014-01-30 18:11:11Z

ACS50001: ACS50001: Relying party with identifier ‘rapattoni:mlsqanetm:entityId’ was not found.

to fix this we did the following, ending up with a successful fiddler run!

image

We had to register a mock application in our instance of AAD setting the logical naming and address so as to conform to the AAD requirements:-

  • change the saml2 entity name to https://rapmlsqa.com/ping in the ping SP, and the AAD “application record” where its known as the application URI. One cannot use badly formatted urns (as originally provided) and one cannot even use URNs (properly formatted) at all (due so some silly microsoft logic).
  • Then, to the application record modify the value of return address field added by default. It should be the actual (https) address of the ping server’s ACS endpoint, listening on the default https port.
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 office365. Bookmark the permalink.