We must be doing something right, for the instance of our STS hosted in the Azure cloud reports in its tracing the following:
at 3, from 157.56) we see the Microsoft Online WS-Trust client (“proxying” the basic auth HTTP request from our client) talking to our STS hosted in Azure Web Role (on 100.69). We know we have this the right way around since we can rdp to the machine, and see its internal LAN address (within the load balancer pool):
Now, the last three HTTP server available are also telling. FIrst, its correct that the UA is the Exchange Services Client (since that the “thick client” library we are using to simulate Outlook, Word, etc). ANd what’s more, the 12.235 is the external NAT address of the corporate firewall!
ok. so it looks like we can hook things together for the first time. Now we just have a to setup some usernames and passwords that are valid for authentication in our STS, and are properly cite dnby the ExchangeServiceClient!
Since we directed the tracing listener to the web page, we can see what WIF objected to (I already know, it’s the wrong uid/pwd!). But let’s check:
We have a nice ws-trust usernametoken-signed request (minted by the office proxy, taking in the basic auth credentials from http and napping them into the token):
and the fault response:
issued to the online gateway, it turned around and gave our client (liv) and www-authorization header response!