Building on the chaining of STSs, discussed at https://yorkporc.wordpress.com/2013/07/21/imposing-a-policy-on-the-rst-of-microsoft-online-and-cite-passport-stuff/, let’s make next two requests to the Exchange Online API’s /wssecurity–enabled endpoint – noting the difference between them. Let’s see the delta – i.e. the cookies minted as a result of the first request succeeding. Success of the first method implies that the server used the full, encrypted saml token that our STS minted (with its external ID) and whose said id Microsoft Online “authentication platform” translated into the internal ID). Success of the second method call could mean the same occurs again, or the cookie is leveraged.
Now one sees the cookie come into play as the second method call reads the inbox (now seeing the message just composed and sent … to our self). Is it used? We don’t know!
Presumably, using the cookie would allow the server farm to avoid the load of verifying the signatures/encryption on the token we supply. So, assuming that is true, could we avoid sending that long token on the nth call (for n>1)!!?
Well this obviously depends on the security policy rules, for the binding. These should tell us whether we send once only, or on each method call.