"400 Bad Request" Error Occurs with Okta SSO - Unable to Log in to VPN
I configured SSO authentication with Okta as the IdP for the Cato VPN Client, but when attempting to connect to the VPN, I receive a '400 Bad Request' error and cannot log in. Setup: "Single Sign-On" has been configured in CMA "Cato Portal" configured in Okta A VPN connection has been attempted using the Cato Client During authentication, the following error message appears: Error Message: "400 Bad Request" What I have tried: I found the following information in Okta's Knowledge Base, but I was unable to locate the corresponding setting in the Cato Portal Make sure that the redirect_uri, http://localhost:8080/authorization-code/callback is registered as an allowed Sign-in redirect URI in Open ID Client for the application being used [Reference link] (https://support.okta.com/help/s/article/The-redirect-uri-parameter-must-be-an-absolute-URI?language=en_US) Question: If anyone has encountered and resolved this issue, I would appreciate any insights on key configuration points or possible solutions. Additional Information: I am using Okta's free Developer edition (https://developer.okta.com/login/) for testing.
"Record Issue" button - what is it for?
The Cato Windows client has included a "Record Issue" button for a long time - but is it actually of any practical use? Whenever I have submitted a support ticket I am never asked to make use of this, but rather been asked to perform a SSS (which is not at all very convenient, especially when attempting to explain to a remote end user how to perform those steps). I now see that the addition of such a button is touted as a major new feature for the macOS Client v5.8 - does this mean that it might actually have become usable for the Windows client as well?
Cato SDP Client to be auto intelligent to login instead of manual logging
I have recently migrated from Netskope to Cato Networks. One issue we have noticed is that users need to login once to Cato SDP client and then "Always-on policy" gets enabled. But users are smart, they don't login to SDP client itself as many sites gets blocked as per policy which they don't want so they don't login once also to SDP client thus making us non-compliant as absence of SDP client makes them vulnerable as they can browse malicious sites as well as can upload company data on public sites which typically gets blocked when connected over SDP client. In Netskope, we just had to push agents to the laptop and no user intervention was required, it automatically detects logged in user credentials so there was no scope for user to not login or bypass security controls. Can't we make zero touch experience for user so that there is no room for escape or delay as now we are totally dependent on user.
