Environment:
Qlik Sense Enterprise on Windows , all versions
Scenario 1:
When setting up SP initiated SAML Authentication with a 3rd party SSL and custom ports, login fails with the following:
"Error 400 - Bad request Contact your system administrator. The user cannot be authenticated by the SAML response through the following virtual proxy"
The certificate was checked to ensure it read Provider = Microsoft Enhanced RSA and AES Cryptographic Provider, but authentication is still failing a 400 error, with very little indication as to what was occurring in the logging.
Custom ports are not always reflected in the metadata, which causes the connection to attempt on the standard secure port (443)
Resolution:
Check the metadata that is uploaded from the Identity Provider in the Qlik Management Console to ensure the port number is not listed, or utilizing the custom port.
Example:
In the metadata, you will see the POST and Redirect URL's using the standard port (443), though port 1443 is specified in the proxy.
Location="https://qlikserver1.domain.local:443/pingfed/samlauthn/"
Change the URL to read the correct custom port number specified in the proxy.
Location="https://qlikserver1.domain.local:1443/pingfed/samlauthn/"
Scenario 2:
SAML is a data format for authentication and authorization. It enables single sign-on (SSO), and thereby minimizes the number of times a user has to log on to cloud applications and websites. Three entities are involved in the authentication process:
- the user
- the identity provider (IdP)
- the service provider (SP)
The identity provider is used for authentication. When the identity provider has asserted the user identity, the service provider can give the user access to their services. Because the identity provider has enabled SSO, the user can access several service provider sites and applications without having to log in at each site.
If SAML Autentication fails in the audit proxy log the following message can be seen:
The identity provider failed authentication. urn:oasis:names:tc:SAML:2.0:status:Requester
Refer to https://msdn.microsoft.com/en-us/library/hh269642.aspx for the status codes.
Resolution:
It may be necessary to check the following:
- On the metadata.xml file set
WantAuthnRequestsSigned=true
- Recreate the metadata file double signing it.
- Set AssertionConsumerService to 2
