On Windows 2012, install http://claimsid.codeplex.com/releases/view/67606 samples and do your best to configure. Configure the certificates, even though they will appear not to properly configure…they do.
Our simplest project for a Ws-trust client and server (hosted in IIS express) was formed by taking directly from the various samples, either in the ACS sample set for the username token (we stole the client) or the best practice sample set for the username server (we stole the Litware STS).
There is now a minimum of fuss – over SSL an RST is sent, and RST-R returned. The request contains a username token with guess what.. a username and password. A SAML blob comes back in the RST-R.
From here, we can look at what we need to do (probably going back in time) to make this compatible with Outlook when working with Office365 endpoints.
We see (from Ping Federate logs) that Outlook sends:
and the (PF) STS sens back for Office365 usage:
We can compare these obviously with the logs of the project’s client/server:
As with the passive STS work, we can assume that the Office365 wants to use the older 2005 profile of ws-trust.
If you use IIS express, don’t forget to set the SSL true property (and find the port). If you use IIS, don’t forget to ensure you add Everyone to the ACL of the (localhost) private keys!