I've just implemented Juniper SSL VPN support in OpenConnect. In many ways it's like Cisco AnyConnect — first you authenticate through a series of HTTP forms, which can be done by the auth-dialog in the user's session, and when you succeed you are rewarded with an HTTP cookie which is given to OpenConnect to actually make the connection — first over HTTP for the control and configuration, with an optional UDP transport to be used wherever possible. So it all fits fairly nicely into the existing model… except for the details of the authentication. Cisco uses a relatively simple scheme with XML forms, intended to be handled by a native VPN client. It's easy enough for libopenconnect to parse those and feed them back in a form that the auth-dialog can display to the user. Juniper, in the other hand, is actually intended to be launched from the web browser. It uses *arbitrary* HTML forms, often including JavaScript and even full Java applet support. The *common* case is not so hard, and OpenConnect will be capable of parsing those forms (with a special case for the invoking the "Host Checker" Java applet which validates that the connecting host meets the configured security criteria). But people can wrap all kind of strange stuff around the authentication process, and the only *full* solution is going to be a real web browser. How feasible is it to embed a browser into the auth-dialog? Would it make sense for it to be *optional*, as a fallback for those with complicated auth setups where libopenconnect cannot cope? Ideally I think it would actually use libopenconnect to do the HTTP traffic because then the client certificate handling will be correct. So perhaps it's just an HTML rendered (and JavaScript+Java support) that we'd need. Any thoughts? TBH I'm most likely to just set it up with what libopenconnect can cope with for now, and leave the more complete browser support as an exercise for someone else... -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature