Microsoft’s Outlook.com email site is all the rage this week. With a clean, responsive interface, many are harping it as a symbol of “the new Microsoft.” Hope springs eternal.
I was disappointed, however, to see this error message after incorrectly typing a password:
Hmmm. Did I miss a change in the security world regarding email address privacy? Hopefully Microsoft will remedy this situation quickly and use the typical (and more private) approach – “That email address and password do not match our records.”
Version 2 of Windows Azure’s Access Control Service (ACS) was released recently. There seems to be some confusion flying about when it comes to which security tokens are provided by protocols or ACS mechanisms. Here’s a quick matrix which we hope will clarify the situation:
So you can acquire a SAML 2.0 token using a SAML protocol (aka, SAMLP), but not SWT or SAML 1.1 tokens.
This matrix also draws attention to other issues:
SWT tokens are the most protocol agnostic. ACS supports rendering SWT tokens from all protocols except SAMLP.
SAML 1.1 are the most protocol specific. If your application requires SAML 1.1, ACS has already made your protocol decision for you. (From a security token perspective, WS-Federation is a more complex special case of WS-Trust)