10-12-2022 01:15 AM - edited 10-13-2022 07:39 AM
Using OKTA provider:
Some times after setting up the SSO correctly from the CMC UI we face some issues like the below:
1. The "Something went wrong error" without passing by the provider page for authentication:
this specific issue happens because the provider xml may have some syntax error or inconsistent tags, as the tags should be like this:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<default>http://www.okta.com/exk4rmwls3taRCAII4x7</default>
<applications>
<application>
<md:EntityDescriptor entityID="http://www.okta.com/exk4rmwls3taRCAII4x7" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIDnjCCAoagAwIBAgIGAXAS7GPsMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQGEwJVUzETMBEG.....</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://incorta.okta.com/app/incorta_myincortadev_1/exk4rmwls3taRCAII4x7/sso/saml"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://incorta.okta.com/app/incorta_myincortadev_1/exk4rmwls3taRCAII4x7/sso/saml"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
</application>
</applications>
</configuration>
2. After passing by the provider page, sometimes we see that page is blank and being re-directed for good with no end:
this issue happens because these URLs that are configured in OKTA side are missing a forward slash "/" at the end of them as shown:
3. When we login from the UI we get this error:
and this error indicates that the certificate is wrong or has some unneeded spaces, So the certificate needs to be checked and to remove every white space.
Using Azure ADFS/ OneLogin providers:
1. The "Something went wrong error" without passing by the provider page for authentication:
this specific issue happens because the provider xml may have some missing or wrong flags, The configurations should be like that:
onelogin.saml2.strict = false
onelogin.saml2.sp.entityid = https://<hostname>/incorta/!<tenant_name>/
onelogin.saml2.sp.assertion_consumer_service.url = https://<hostname>/incorta/!<tenant_name>/
onelogin.saml2.sp.assertion_consumer_service.binding = urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
onelogin.saml2.sp.single_logout_service.url = https://<hostname>/incorta/logout.jsp?rediredtUrl=.
onelogin.saml2.sp.single_logout_service.binding = urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
onelogin.saml2.idp.entityid = from the metadata.xml
onelogin.saml2.idp.single_sign_on_service.url = from the metadata.xml
onelogin.saml2.idp.single_sign_on_service.binding = urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
onelogin.saml2.idp.single_logout_service.url = from the metadata.xml
onelogin.saml2.idp.single_logout_service.binding = urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
onelogin.saml2.idp.x509cert = MIIEgDCCA2igAwIBAgIUbFFKN5QXICYDvuGJPJYXZ/0awOAwDQYJKoZIhvcNAQEF .......
2. After passing by the provider page, sometimes we see that page is blank and being re-directed for good with no end:
this issue happens because these URLs that are configured in OKTA side are missing a forward slash "/" at the end of them:
3. When we login from the UI we get this error:
and this error indicates that the certificate is wrong or has some unneeded spaces, So the certificate needs to be checked and to remove every white space.
4. After passing by the provider's page we get a static blank page:
this issue happens because of 2 reasons:
- Sometimes the 3 parameters from the Email tab under the Tenant's configurations from the CMC aren't correct:
Server host: should be the hostname of the server which is Incorta UI URL.
Server port: 443
Server protocol: HTTPS
- Sometimes the loginName isn't passed to the SAML response and this causes this issue as well:
1. The loginName should be written like that on the provider side, with small l and capital N.
2. Sometimes the loginName name is there correctly however isn't passed to the SAML response, the loginName field was there however we should click on it and there will be a small check box inside asking us to include it in the SAML assertion.