Cannot get it to work with PingOne

[salmineo]

Unknown document type error. I tried with v2.16.0, and upgraded to v2.2.6.2, same error.

This attempts is with native PingOne users; I have also tried with PingFederate as the id repository for PingOne (my actual use case), but that results in a different error when redirecting from PingOne to PF for authentication.

C:\Windows\system32>saml2aws --version
2.26.2

C:\Windows\system32>saml2aws login
Using IDP Account default to access PingOne https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=b4533ac6-a739-47a9-aa6
1-2c54405bbfe0&idpid=755673ec-f5ff-4d39-aae2-f43de7e8a6e7
To use saved password just hit enter.
? Username testuser
? Password ***********

Authenticating as testuser ...
error authenticating to IdP: Unknown document type

C:\Windows\system32>saml2aws configure
? Please choose a provider: PingOne
? AWS Profile trey
? URL (https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=b4533ac6-a739-47a9-aa61-2c54405bbfe0&idpid=755673ec-f5ff-4d
? URL https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=b4533ac6-a739-47a9-aa61-2c54405bbfe0&idpid=755673ec-f5ff-4d3
9-aae2-f43de7e8a6e7
? Username testuser
? Password
No password supplied

account {
  URL: https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=b4533ac6-a739-47a9-aa61-2c54405bbfe0&idpid=755673ec-f5ff-4d
39-aae2-f43de7e8a6e7
  Username: testuser
  Provider: PingOne
  MFA: Auto
  SkipVerify: false
  AmazonWebservicesURN: urn:amazon:webservices
  SessionDuration: 3600
  Profile: trey
  RoleARN:
  Region:
}

Configuration saved for IDP account: default

With PingFederate as the id repository for PingOne:

C:\Windows\system32>saml2aws login
Using IDP Account default to access PingOne https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=b4533ac6-a739-47a9-aa6
1-2c54405bbfe0&idpid=0cc19722-1614-49ca-9afa-ad9418ccfda4
To use saved password just hit enter.
? Username trey
? Password ********

Authenticating as trey ...
error authenticating to IdP: error following: Post https://pingfed-idp.ad.jibboo.org/idp/rl3hV/resumeSAML20/idp/SSO.ping: dia
l tcp 172.16.6.129:443: connectex: No connection could be made because the target machine actively refused it.

C:\Windows\system32>

The resume URL does not have the correct port for my PingFed - it should be using 9031, not 443. Strangely, when I changed my PingFed to use 443, I received the same error but 'tcp 172.16.6.129:9031'.

It does work for me if I use PingFed as the IdP directly.

[devoprock]

@wolfeidau ,Can you please help us on above issue.

[gliptak]

Maybe review your Ping configuration (in particular re. https://pingfed-idp.ad.jibboo.org and it's port)

[salmineo]

Maybe review your Ping configuration (in particular re. https://pingfed-idp.ad.jibboo.org and it's port)

As I stated, it does work as expected if I use PingFederate as the IdP directly for AWS.

There is an error 'unknown document type' if I use the PingOne cloud IdP instead of PingFederate.

When I try to workaround it by having the PingOne cloud IdP redirect to the on prem PingFederate IdP, that is when I get the port issue. That is not the primary use cause, just an attempt at working around the original problem.

[ghost]

Had same error and used workaround but don't know until when it'll last. I've installed mobaXterm, opened - powershell within. Re-initialized saml2aws configure, Did all the setup I've done before to initialize connection. And suddenly it unblocked the default powershell access for saml connection too.

⭐ I'd like saml2aws had some reset config option, or saml2aws configure itself include some sort of full reset, idk, it'll be helpful.

Also, don't know the root cause of this. The data was ok. Single thing changed from the initial setup - password was updated in ActiveDirectory. By introducing newly updated password it eat all introduced info either at configure option or interactively but ended up in IdP: Unknown document type anyway. Maybe it ignored authentication somewhere under-the-hood.

[edeastwood]

I'm seeing the same error with ADFS, ADFS2 and AzureAD providers. I can access the page in the browser and retrieve it with curl. I think in my case (no proof yet) that this is due to corporate network infrastructure (e.g. proxy). The same config and same providers work fine on another machine.

[edeastwood]

I guess there are multiple causes of this error but I've now proved the cause of mine was down to a zscaler proxy. Setting the https_proxy environment variable has fixed it for me. In PowerShell this was

$env:https_proxy=<your proxy here>