Unexpected behavior with SSO

Got a problem with Viscosity or need help? Ask here!

lkinley

Posts: 9
Joined: Thu Jan 06, 2022 5:36 am

Post by lkinley » Tue Jan 25, 2022 3:46 am
I have two scenarios that have unexpected results.

1. After disconnecting from a VPN and reconnecting, the SSO login process will fail with error:
Code: Select all
Jan 21 4:27:20 PM: State changed to Authenticating
Jan 21 4:27:20 PM: URL authentication request received from server. Attempting to load URL...
Jan 21 4:27:22 PM: Error: Authentication URL failed to load. Unknown.
Jan 21 4:27:22 PM: State changed to Disconnecting (Open URL Failed)
Jan 21 4:27:22 PM: SIGTERM[hard,] received, process exiting
Jan 21 4:27:24 PM: OpenVPN has exited. Exitcode = -1
An immediate retry always succeeds without issue. Disconnect and try again, same issue.

2. If a reauthentication is forced during an active connection, Viscosity will properly go into "Authenticating" state. However, then two unexpected things happen. First, the SSO window will stay open after the authentication is complete. It will disappear eventually, but it looks like a 30 second timeout has occurred. The status will not change to "Connecting" until it does close. Next, the status will not change from "Connecting" to "Connected". It just stays in that status while the VPN connection continues to operate normally. Log output:
Code: Select all
Jan 23 12:17:25 PM: State changed to Connected
Jan 23 1:14:11 PM: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1549', remote='link-mtu 1550'
Jan 23 1:14:11 PM: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Jan 23 1:14:11 PM: State changed to Authenticating
Jan 23 1:14:11 PM: URL authentication request received from server. Attempting to load URL...
Jan 23 1:14:13 PM: Authentication URL successfully loaded.
Jan 23 1:14:42 PM: State changed to Connecting
For clarity, the OpenVPN SAML service provider (written by me) is forcing the reauth when the server does key renegotiation.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Tue Jan 25, 2022 8:55 am
Hi Ikinley,

For both of these, could you please post (or email if you prefer, this is a public forum) a complete copy of each log with the verb level increased - https://sparklabs.com/support/kb/articl ... ed-logging

For 1., can you please provide a complete copy of the log so we can get an idea of your system setup and we can look into that. Can you also clarify that you are effectively in a loop where every second connection works, with each in between failing with this error and you are disconnecting manually, the connection isn't failing or dropping out from it's connected state, or you are disconnecting before the connection is finished connecting for example?

For 2., there are a few parts to this. Basically nothing is indicating to the client on a reauth that it is successful as OpenVPN doesn't send a message, traffic keeps flowing or it's cut. We will need to make a change to our code to handle this scenario as it's not something we considered, but this will only handle the status staying in a connecting state. Unless you have a specific reason to do this, we highly recommend using auth-tokens for reauth instead.

In regards to the webview staying open, you will need to indicate to Viscosity that authentication is finished via a CONNECT_SUCCESS message via javascript:
Code: Select all
window.postMessage({"type": "CONNECT_SUCCESS"})
Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

lkinley

Posts: 9
Joined: Thu Jan 06, 2022 5:36 am

Post by lkinley » Wed Jan 26, 2022 5:58 am
I will send logs to the support email.

#1 There doesn't seem to be a consistent pattern. It has gone into a every-other-time pattern, but not always. For clarity, I am fully connecting and then manually disconnecting before trying to connect again.

#2 Since I am using management-client-auth mode on the server, each REAUTH has to be confirmed via the management interface. I am confirming via client-auth-nt comand. The aforementioned behavior arose when I experimented with sending a client-pending-auth OPENURL command to fully reauthenticate after a certain period of time. The log file sent has a very short reneg period (2mins) to speed up the testing and I forced the reauthentication in same time period.

As for the webview staying open, it disappears just fine on initial authentication but doesn't on the reauthentication. I will try out the javascript method.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Thu Jan 27, 2022 8:39 am
Hi lkinley,

Thanks for sending through the logs and the clarification, we'll take a look when we can.
#2 Since I am using management-client-auth mode on the server, each REAUTH has to be confirmed via the management interface.
The auth-gen-token command on the server will supersede the management-client-auth option for reauths and is what we recommend using - https://sparklabs.com/support/kb/articl ... -gen-token
I am confirming via client-auth-nt comand. The aforementioned behavior arose when I experimented with sending a client-pending-auth OPENURL command to fully reauthenticate after a certain period of time. The log file sent has a very short reneg period (2mins) to speed up the testing and I forced the reauthentication in same time period

As for the webview staying open, it disappears just fine on initial authentication but doesn't on the reauthentication. I will try out the javascript method.
As previously mentioned, reauths don't inform the client in any way they are successful. All you're doing is telling the server to continue to allow traffic from the client after the authentication process. If this is denied, the client will eventually just time out. Because of this, Viscosity has no way to know authentication is complete from the OpenVPN side so you will need to tell the webview to close if you wish to use this method for reauths instead of auth tokens.
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

lkinley

Posts: 9
Joined: Thu Jan 06, 2022 5:36 am

Post by lkinley » Sat Jan 29, 2022 9:42 am
Thu Jan 27, 2022 8:39 amEric wrote:

The auth-gen-token command on the server will supersede the management-client-auth option for reauths and is what we recommend using - https://sparklabs.com/support/kb/articl ... -gen-token
This has not been my experience. I have auth-gen-token in the server config but reauth must still be confirmed via the management port or it will disconnect. Am I missing something?
Thu Jan 27, 2022 8:39 amEric wrote:
As previously mentioned, reauths don't inform the client in any way they are successful. All you're doing is telling the server to continue to allow traffic from the client after the authentication process. If this is denied, the client will eventually just time out. Because of this, Viscosity has no way to know authentication is complete from the OpenVPN side so you will need to tell the webview to close if you wish to use this method for reauths instead of auth tokens.
That's fine, I will abandon this approach as it was more of an experiment than anything I had to have.

Thanks for the feedback.

-Lance

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Jan 31, 2022 1:17 pm
Hi Lance,

I've modified our examples to include support for auth-gen-token. Hopefully this clears up how to implement this and it will hopefully be useful for others implementing SSO with OpenVPN & Viscosity as well. You can find the changes to our example for your reference and some more information in our KB article below:
https://github.com/thesparklabs/openvpn ... d6a3326bf5
https://sparklabs.com/support/kb/articl ... uth-tokens

The summary is you will need to do the following (I believe you had implemented some of this already and I misunderstood your earlier posts):
  • Add the following command to the server configuration -
    Code: Select all
    auth-gen-token 0 external-auth
  • Modify your management interface to push an auth-token-user on connect
  • Handle the CLIENT:REAUTH command via management. This is basically the same as CLIENT:CONNECT except you are checking the session_state value, and can use other environment variables from ESTABLISHED to add extra security.
Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Jan 31, 2022 4:03 pm
Hi Lance,

Just following up on the logs you sent. I have confirmation from Microsoft that the webview is crashing and there are several bugs on their list (which is private so unfortunately I can't get more information than this). There should be a dump in the Event Viewer at the time it occurs with more information. This may reveal a specific issue with your webpage that is causing the crash, or information we can use to work around it.

Otherwise, I'm afraid it's just a matter of waiting for updates from Microsoft that correct these bugs.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

lkinley

Posts: 9
Joined: Thu Jan 06, 2022 5:36 am

Post by lkinley » Sat Feb 05, 2022 6:14 am
Thanks for the update.

I don't see any crash dumps in or under the AppData/Roaming/Viscosity/webviews/EBWebView folder.

Would they be somewhere else?

lkinley

Posts: 9
Joined: Thu Jan 06, 2022 5:36 am

Post by lkinley » Sat Feb 05, 2022 4:31 pm
I re-read that and realized you meant the Windows Event Viewer.

I don't see anything there for Viscosity at the relevant timestamps, however.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Feb 07, 2022 3:33 pm
Hi Lance,

They wouldn't be tagged as Viscosity. They would be tagged as Microsoft Edge or WebView2 or something like that. Effectively anything that has a timestamp up to a couple of seconds either side of the issue occurring.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
12 posts Page 1 of 2