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.
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.
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.
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 ominousResponse 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.