This means your authenticated identity is not in the identities service, so SASLogon cannot build your authentication token. This usually means either you have not configured identity provisioning, or your identity provider is using a different field for account ID than what is being sent by your OIDC provider. ... View more

You must have either discoveryUrl, tokenKey, or tokenKeyUrl populated, but no one of them is mandatory. ... View more

This error suggests the tokenKey or tokenKeyUrl field is empty in your sas.logon.oauth.providers definition. ... View more

The table work.users is built from a loop of all users found in the identities service. Removing the obs limit, or setting it to a value higher than the total number of users, would ensure all users are added. Without knowing the error you are encountering, I can't say why you are encountering an error. ... View more

The SAS trust store used by Java is <SASHome>/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.jks. This output shows the certificate was issued today (Mar 4) and is a self-signed certificate: Subject: CN=mid.com, OU=Data , O=company, L=XX, ST=XX, C=GB Validity: [From: Tue Mar 04 12:45:23 GMT 2025, To: Wed Mar 07 12:45:23 GMT 2026] Issuer: CN=mid.com, OU=Data, O=company, L=XX, ST=XX, C=GB That issuing certificate (as this is self signed, being the actual certificate) needs to be in the SAS Trust Store. You can check this against trustedcerts.pem or .jks using keytool. For example: <SASHome>/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/keytool -printcert -file <SASHome>/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.pem | grep -E '(Owner:|Issuer:)' Confirm an "Owner: CN=mid.com, OU=Data, O=company, L=XX, ST=XX, C=GB" is present. Given the certificate was just issued, it's unlikely it's in the trust store already if you didn't add it. You would do so using the SAS Deployment Manager task as documented here. This must be done for every SAS Installation Directory (SASHome): Manage Certificates in the Trusted CA Bundle Using the SAS Deployment Manager https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/secref/n0n1y5gwevy312n13h5bm4yf6quy.htm You may also want to confirm the certificate's "Subject Alternative Names" contains an entry for the host serving the certificate. ... View more

Sounds like you're connecting successfully but don't have permission to see anything, or nothing exists. You may want to add sastrace option to get additional detail on what's being sent. ... View more

This failure occurs when a java process fails to validate a certificate. Generally speaking certificate validations can fail because the certificate has expired, the certificate is issued by a CA not in the SAS trust store, or the certificate issued using an unsupported signature algorithm, for example. You can try adding the java option -Djavax.net.debug=ssl to the web application server where you are seeing this error to get more information. ... View more

Do you still see those special characters in the URL? What version of Viya are you running? What error/warning messages do you see in the ingress controller log? ... View more

Are you able to authenticate using the /SASLogon endpoint? ... View more

Viya is only supported using a single LDAP server for identity provisioning (multi-tenancy aside). If you need to use multiple LDAP servers you would need to set up some sort of LDAP proxy so Viya only needs to be provided one LDAP server hostname. ... View more

What version of ingress-nginx are you using? Those special characters are regex from the ingress definition, which makes me think you may be using 1.12+ which has some additional requirements. https://go.documentation.sas.com/doc/en/sasadmincdc/v_061/itopssr/n1ika6zxghgsoqn1mq4bck9dx695.htm#p1eeoaos2nm7jsn1q3ymhui62j9v ... View more