ADFS and SAML2 Unable to Pass SAML Extension for Requested Authentication Context

[aj-stein-nist]

Hello, I am trying to use saml2aws in a new environment with a new employer and I am encountering some issues. I was able to work with the AWS cloud support team and worked with them using the reference Python scripts from the AWS article for using ADFS+SAML2.0 to generate session tokens for the CLI. It does not require MFA, but has intermediate forms-based auth with NTLM and an AD domain account via ADFS. Most importantly, my org seems to require HTTP request parameters that supply a RequestedAuthenticationContext, which is part of a SAML 2.0 Extension specification.

Therefore, the following URL from the ADFS endpoint works.

https://host.domain.tld/adfs/ls/idpinitiatedsignon.aspx?loginToRp=urn:amazon:webservices&RequestedAuthenticationContext=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

The following URL, without the parameter that enables that extension component, the SAML authentication always fails with a Python error Response did not contain a valid SAML assertion.

https://host.domain.tld/adfs/ls/idpinitiatedsignon.aspx?loginToRp=urn:amazon:webservices

This is because it silently fails and with saml2aws fails likewise with the ominous Response did not contain a valid SAML assertion like others in #144, but ostensibly for other reasons. ``saml2aws login --verbose` and DEBUG log statements don't tell much because, even from Python experiments, the form comes back but the necessary form fields with the assertion will come back missing. There are no HTTP error codes or HTML indicators this or other tools pick up.

I checked the Golang code, and it even with saml2aws configure and pass in the correct URL, those parameters are likely truncated. It is hard-coded to construct the ADFS URL and end it with a custom or one of the common AWS URN parameters and that's it.

Is adapting this something that you would consider supporting @wolfeidau? Is this inherently something saml2aws would want to enable, even if a PR were contributed? Sorry, I am new to this kind of setup and I am not sure if this extension behavior and the HTTP parameter requirements are novel, commonplace, and how that figures into how you want the tool to be extended or maintained.

[christianmeyer]

@aj-stein-nist check our fix from #795 - we use that in production since >2y without (new) issues.