The project I built is download from here and the desired output is shown below (using the Fiddler tool and a Federation ‘inspector’, all from community members):-
To repeat the experiment using school-boy computing apparatus, install visual studio 2010 and the WIF SDK.
Then add the website, using the Claims Aware website template.
On that website project, run the STS wizard and add a (passive) STS project. The former is the relying party of service provider (SP) relying on the signed assertion produced by the latter IDP – the asserting party releasing an identity claim about someone or something. Note the default.aspx.cs file.
To change the output message formatting from its defaults, perform the following modifications to the pre-generated code in default.aspx.cs:
At 1 declare the serializer classes (for the older message formatting regime that we seek).
At 2, use the serializer in a replacement method call that processes the signin message received from the SP, requesting a response with assertion. You will need to resolve types, which will add package references:-
While you are at it, you MAY wish to maximize interoperability (at the cost of introducing “relative” lower strength in your crypto). By using SHA1 (or MD5), it will be now 10 years rather than 20 years before anyone attacking you that you actually care about can spoof the signature checksum – on your message whose noted expiry is 5m from now anyway…). Certain sites upon receiving assertions verify signatures only when signed with the RSA/SHA1 crypto combination and 1024-bit public keys
So that the assertion be signed with RSA/SHA1, alter the constructor of the STS configuration class thus:
We can go further into the maximum interoperability argument and ensure the assertion has an Authentication Statement indicating an authentication instant, authentication method, subject name and a couple of authorization attribute required by Azure AD (in its Office 365 incoming Federation Gateway incarnation).
This requires two steps:
Step 1: make claimset (note the Prip UPN (http://schemas.xmlsoap.org/claims/UPN) , particularly) and assign the claimtype of the name(identifier) claim
and in the STS class’ call back method for GetOutputClaimsIdentity() method apply our trick to make Authentication Statements appear in the (SAML 1.1) output assertion:
Step 2: ensure the output ClaimsIdentity has isAuthenticated property set true
With these additional changes we get as output on the wire something I’ve sought for 2 years!
Now the open question is: is this response compatible with (i) Ping Federate’s ws-fedp SP, (ii) the Shibboleth ws-fedp SP, and (iii) Office 365?
Yes, I’ve gone back a decade and laid out the non-optimal steps in schoolboy programming style – but that’s what maximum interoperability and maximum tutorial value often entails (since highly politicized vendors/academics ensure modern profiles don’t actually interwork in the wild, using some semantic trick or other to help “structure the market”)
Help on getting this far due to : Ping Identity (lots and lots of what-to and how-to), Steve Syfuhs, (how to go back in time in WIF), Dominick Baier (for Fiddler ws-fedp inspector and patience beyond measure, given the likes of me).
So, to testing with Ping Federate! lets create a connect from its SP agent to this STS – intending the websso assertion to play the role of a OAUTH grant:
Concerning the mapping from SAML assertions to OAUTH persistent grants (one of the advantages of paying for commercial grade servers!)
Concerning the mapping from assertion to access token we play a little:
And of course we import the STS’ certificate into the Ping Federate IDP connection, exporting it from windows thus:
makinga complete Ping Federate IDP OAUTH-IDP Connection of
When we try it we in the OAUTH context, acting as the phone app doing a redirect via its web browser to get the first authorization_code after a user authentication (via ws-fedp websso interaction)
We get an interworking success between (non SAML2P) WIF IDP and Ping Federate (for My first time)!
and RSA-signed JWT of
Just one gotcha to note in the original Ping Federation server IDP connection config: one has to use the SP’s wrealm to give what is normally indicated in the wreply:
Perhaps repeat the steps – and let me know what factoid I’ve omitted from the schoolboy’s science project writeup.
To make the assertion from the STS indicate am authentication subject name with a particular format,
one makes a slight modification of the code:
Thanks to Steve Syfuhs