Now the madness with ADFS2 SAML assertions via WS-Trust 1.3 – and how they are not valid for use with Amazon Web Services (AWS).

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion<br /> A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Responses must contain SubjectConfirmatonData with a Recipient and NotOnOrAfter

This failed due to a missing Recipient attribute on the SubjectConfirmationData element. Of course; I can’t modify the assertion to add the missing Recipient; as the SAML token is signed:

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion<br /> A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Response signature invalid

Second fail is because I’ve modified the assertion to add the missing attribute; but now the signature is invalid.

When you get an assertion from the ADFS Identity Provider via the IdP Web Landing Page, for AWS, the assertion includes a “recipient”:
<subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><br /> <subjectconfirmationdata NotOnOrAfter="2015-02-08T22:48:18.520Z" Recipient="https://signin.aws.amazon.com/saml"></subjectconfirmationdata><br /> </subjectconfirmation>

When you ask for an assertion from the WS-Trust 1.3 endpoint; it is missing:
<subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><br /> <subjectconfirmationdata NotOnOrAfter="2015-02-09T05:03:10.517Z"></subjectconfirmationdata><br /> </subjectconfirmation>

Seems to be a common problem with ADFS2 whereby ADFS1 did it correctly. It’s not just me…

In the original SAML 2.0 Core spec – Line 725 – Recipient is an optional attribute in the SubjectConfirmationData element. However in subsequent errata for the specification, Errata 02 in May 2007, made it mandatory. Errata 05 still includes this requirement.

At lease one bearer element MUST contain a element that itself MUST contain a Recipient attribute containing the service provider’s assertion consumer service URL

Of course; Amazon adhere to the Standard:

The value of the Recipient attribute inside the SubjectConfirmationData element must match the AWS endpoint (https://signin.aws.amazon.com/saml)

It seems that ADFS2 doesn’t provide valid SAML 2.0 assertions issued via the WS-Trust 1.3 endpoint. Since this has been a standard since for almost 8 years, how does ADFS2 even claim to be standards based.