Update for SAML (long username/password) support

[m4dc4p]

Based on patches found at https://github.com/samm-git/aws-vpn-client, this updates OpenVPN for compatibility with AWS' SAML based authentication.

Thank you for your contribution

You are welcome to open PR, but they are used for discussion only. All
patches must eventually go to the openvpn-devel mailing list for review:

• https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Please send your patch using git-send-email. For example to send your latest commit to the list:

$ git send-email [email protected] HEAD~1

For details, see these Wiki articles:

• https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation
• https://community.openvpn.net/openvpn/wiki/Contributing

[m4dc4p]

The repository I linked applies some patches to increase the buffer size used to hold command line arguments, and some others, which ultimately allow openvpn to be used with SAML-based authentication.

If the changes seem solid, it seems to make sense to get them into the official release.

[schwabe]

Those patches are breaking compatibility with existing OpenVPN servers/clients. There is also no documentation or examples or other indicates how these changes would help with anything.

OpenVPN already supports SAML auth, see management-notes.txt and auth pending support.

[m4dc4p]

That's fantastic - thanks for the pointers! I'll dig in. Much appreciated.

[sant123]

@m4dc4p did it work for you?

@schwabe I think it should not be breaking compatibility. Basically is adding more memory to store the SAML response (since it can be large like 11Kb) and send the credentials through the VPN Server.

[m4dc4p]

@sant123 Yeh, this commit mostly worked for me. What I learned was my vendor is using the "Dynamic Challenge" protocol, and the SAML response is pushed to OpenVPN via the 'password' command in the management interface. To support that, you still need to increase the storage size of the username and password buffer. I've pushed an update with minimal changes needed.

See #295.

[schwabe]

@sant123 the patch definitively breaks compatiblity as it changes some fields from 2 byte to 4 bytes on the wire protocol without caring about compatibility at all. (e.g the change from if (!buf_write_u16(buf, 0)) to if (!buf_write_u32(buf, 0))).