Support non-AnyConnect protocols via libopenconnect API about ics-openconnect HOT 7 OPEN

How does the auth-dialog flow look on those protocols? That's the part of the app I've been most reluctant to touch, since it's so hairy.

I would have figured that the configuration options (like CSD) would vary per-protocol, too? Any other UI changes?

from ics-openconnect.

How does the auth-dialog flow look on those protocols? That's the part of the app I've been most reluctant to touch, since it's so hairy.

Yeah, that code is hairy in all the front-ends ☹️. Fortunately, the auth-dialog flow is essentially identical, building up a form structure that's the same as what is used for AnyConnect. After adding multi-protocol support to the NM plugin, Juniper and GlobalProtect login forms "just worked." (username/password fields may be named differently, but this shouldn't affect the behavior of the front-ends, because the field types, e.g. OC_FORM_OPT_TEXT, are named similarly.)

CSD is similar. Juniper uses a mechanism called TNCC and GlobalProtect uses one called HIP, which are essentially equivalent to CSD and can similarly be invoked by wrapper scripts. One tricky detail is that, for GlobalProtect, the HIP script has to be executed during the connection phase, rather than the authentication phase… I mentioned this on the official mailing list a few months ago, and wrote a quick-and-dirty patch for the NM plugin to support it.

Other than that, the non-AnyConnect protocols pretty much work identically. They set the routing environment variables identically, etc.

from ics-openconnect.

One tricky detail is that, for GlobalProtect, the HIP script has to be executed during the connection phase, rather than the authentication phase… I mentioned this on the official mailing list a few months ago, and wrote a quick-and-dirty patch for the NM plugin to support it.

Actually, I don't think this will cause any problems at all for the Android plugin, because you're doing both the authentication and the connection phase in a single process, so all the required configuration variables will be there. 👍

from ics-openconnect.

For AnyConnect, the Android client uses a static CSD script that posts the right incantation to the Cisco-specific URL. It's not configurable.

If we skip TNCC/HIP for now, what is the expected impact on users?

from ics-openconnect.

Ah, interesting. An equally simple shell script works for GP (it literally does nothing but output an XML blob to stdout, filled in with a few environment variables).

In my experience, few Juniper VPNs use TNCC, so even without TNCC support I think it would be useful.

from ics-openconnect.

tl;dr If you just openconnect_set_protocol, almost everything will Just Work.

The only expected exception is CSD/HIP/TNCC.

from ics-openconnect.

I added support for the multi-protocol API to the Java bindings and test application… also sent this to the mailing list.

See this diff: dlenski/openconnect@2f270d2...master

	public static final int OC_PROTO_PROXY = 1;
	public static final int OC_PROTO_CSD = 2;
	public static final int OC_PROTO_AUTH_CERT = 4;
	public static final int OC_PROTO_AUTH_OTP = 8;
	public static final int OC_PROTO_AUTH_STOKEN = 16;

	public static class VPNProto {
		public String name;
		public String prettyName;
		public String description;
		public int flags;
	};

	public static native VPNProto[] getSupportedProtocols();
	public synchronized native String getProtocol();
	public synchronized native int setProtocol(String protocol);

I can now connect to a GlobalProtect or Juniper server using the Java test application. 😀 🍺

If we skip TNCC/HIP for now, what is the expected impact on users?

At least for GlobalProtect, adding support for HIP to the Android application should now be as simple as putting hipreport.sh into the Android application as csd-gp.sh (alongside csd-anyconnect.sh).

		String csd_wrapper = "./csd-" + lib.getProtocol() + ".sh";

from ics-openconnect.