-- StarterSTS is a compact, easy to use security token service that is completely based on the ASP.NET provider infrastructure. It is built using the Windows Identity Foundation and supports WS-Federation., WS-Trust, REST, OpenId and Information Cards.
I studied the old version, carefully. It taught me alot about how WIF and claims are supposed to interact with the rest of the web framework. It was a good primer on ActAs tokens, and enabled to better understand the material on multiple tokens, as presented
in Microsoft Press books on the Windows Identity Framework.
I also studied the openid bridge code for starterSTS. This case is interesting in that a claims-driven app talks to an RP that talks to ACS that talks to starterSTS (over ws-fedp) that talks to openid asserting parties. This differs from the case of ACS
talking to a custom openid asserting party directly.
When ACS talks to an openid asserting party, the resulting token minted by ACS has no authenticationStatement; and thus fails (using the default rules generated for the Google provider say) to interwork with the traditional ws-fedp relying party
handler for that token. Id love someone to tell me how to configure ACS otherwise, so I can use ACS+Google to logon to my 300 websites...
Question: Does StarterSTS by any chance create a SAML token with an authentication statement, when bridging to its openid provider to ACS?
If so, I confident that ACS could then pass through those authenticationStatements - if any - and thus deliver those google claims to the ws-fedp engine used at our sites.