According to Wikipedia, Microsoft Active Directory Federation Services (ADFS) is:

… a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.

ADFS can provide Single sign as an identity provider to users, but what if a developer needs the same sign on outside of “browser land”? One option is to scrape webpage responses, but a better option is receiving a SAML Assertion using SOAP endpoints exposed via Microsoft ADFS, as long as they are enabled. You can use SOAP 1.2 with WS-A Addressing and mixed message security with the username/password in the SOAP headers secured over HTTPS, and get a valid SAML assertion.

There is Mex Endpoint (Anonymous by default) provided by ADFS2 or greater (if not disabled) at
https://youradfsserver.com.au/adfs/services/trust/mex
If you want to play with SOAP based claim requests, use a tool like SoapUI and consume the Mex endpoint as the WSDL. You can then construct Soap messages, and see if you get a valid response – which would contain an assertion.

The SOAP Endpoint for requesting a SAML token using WS-Trust 1.3 and mixed security would be
https://youradfsserver.com.au/adfs/services/trust/13/usernamemixed

The client credentials are included in the header of a SOAP message. Confidentiality is preserved at the transport layer (SSL/TLS); hence a usernamemixed endpoint.

Here is an example SOAP request for usernamemixed:

You can also use curl to post the soap request as shown:

Given all that; this actually won’t work for AWS; given ADFS2 actually breaks the SAML2.0 standards updated in 2012. Next post will detail this.