testing ws-fedp element of service from Azure/ACS. Using Google as the IDP.

[Peter Williams]

Anyone interested in testing the ws-fedp support of Shib SP in a bridging scenario. The goal is to see what breaks because of a particular pattern.

I finally figured how to make Azure/ACS (Microsoft websso bridge) talk to PingFederate - which enforces the "PRIP" profile of ws-fedp. The "ACS pattern" should remind one of the SAML2 IDP proxy flow. The PRIP profile requires an asserting party to act as-If ADFS. This means sending an AuthenticationStatement to the Relying Party, whose element bears an authentication method, instant and associated NameID.

When ACS bridges to ADFS, one can configure a default (claim mapping) rule set that enables ACS as bridge to act as a (re-) asserting party, satisfying PRIP also. Interested folks should now be able to test the path ADFS->ACS->Shib-SP, where the Azure/ACS jsonp-based homerealm selector ought be invoked (*) when initiating sp-initiated websso.

When ACS is configured to bridge Shib-SP to Google accounts, by default the rule set cannot talk to PingFederate (or Shib-SP, I suspect). By default, the rules fail to induce the asserting party to add the PRIP-required AuthenticationStatement to the outgoing assertion. However, one can add 2 rules to rule sets targeting PingFederate (or Shib-SP, presumably). These can induce the ACS, as asserting party, to add the mandatory AuthenticationStatement. This addition allowed me to complete an sp-initiated websso run, passing through the ACS homerealm selector and landing on Google (as IDP). As a result, the SP ultimately consumed a signed ACS assertion containing subject identity information sourced to Google.

I see no reason why this very useful flow should not work with Shib-SP, or a Shib-IDP v3 that expects to be part of an (ws-fedp) IDP proxying chain.

(*) the default ACS Homerealm selector shows no UI when there is only one possible IDP for a realm (SP EntityID); simply requesting an assertion from that only choice. One could change this UI behavior by no longer consuming the ACS HomeRealm's UI while consuming the alternative jsonp feed of possible IDPs. Then, one presents one's own UI concept - taking care not to introduced xss vulnerabilities, of course.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20111025/e9216022/attachment.html