On 2013-06-15 18:16, Kevin Cernekee wrote: > On Thu, Jun 13, 2013 at 12:14 PM, Joel Johnson <mrjoel at lixil.net> > wrote: > For the XML POST processing, it looks like it's not properly (fully?) > processing the --authgroup parameter to use the selected group (as long > as > it's returned in the list as being available). Instead of blindly using > the > tunnel-group and group-alias offered initially, it should use what is > specified. I'm not familiar with the details and differences between > the > <group-select> and <tunnel-group>, but this looks quite suspicious. > > <tunnel-group> and <group-alias> are in the <opaque> section. I'm not > sure it's such a good idea for the client to change anything in there. > The Cisco client seems to leave it alone. > > What I see when I feed your server responses to the official > AnyConnect client is that when the user selects e.g. GROUPC_VPN from > the dropdown, the Cisco client sends a "change group" message to the > server: > > <?xml version="1.0" encoding="UTF-8"?> > <config-auth client="vpn" type="init"> > <version who="vpn">3.1.00495</version> > <device-id>linux</device-id> > <group-select>GROUPC_VPN</group-select> > </config-auth> > > Then it redraws the login dialog when it gets the response back. The > new server response tells the client which group to show as selected. > > I couldn't deduce your server's hostname so I can't tell for sure, but > my guess is that your server rewrites the <opaque> contents based on > the newly selected group. It might also be configurable to send a > completely different set of form fields for different group > selections. > > So maybe the <group-select> option only tells the server "send me a > new form with GROUPC_VPN selected," and if you submit your credentials > immediately, it takes the group ID from the <opaque> section instead > of the <group-select> value. Does this jibe with the behavior you saw > (i.e. would you see "Login failed" if you tried to log on to > GROUPA_VPN)? > > One thing that (lib)openconnect could do to work around this is to > prompt the user for just the group first, then after he hits submit, > prompt for the remaining form fields (skipping the group dropdown). > Are you willing to be the guinea pig? Sure, I'm more than happy to help work the issue. For completeness, yes, I would have seen an authentication error connecting to the initial server response. I've been able to confirm what you surmised, that when sending the change group message (I'm using using direct connections to get the raw responses, not through any client) the new response from the server does indeed reflect the modified value in the opaque element. Additionally, using GroupC highlights one thing I mentioned in my original email, that the friendly name wasn't displayed. With the new response, the tunnel-group is the friendly name, and the group-alias is the name returned in the options list and used for the group-select. That is a bit backwards from what I would expect, using what is called the alias as the selection key, but so be it. One item I found odd in testing to make note of, is that if an invalid group-select is specified, no error is indicated, the server response just falls back to the default group as being indicated in the opaque section. Sounds like checking the initial response, comparing it to the --authgroup value provided (read the opaque section?), and sending a group-select if the group-alias doesn't match (and iff the requested group is a valid option in the list), and then send the credentials. It sounds like what you're proposing, as long as the user isn't prompted when --authgroup is specified originally as a command argument (I just had to test running it without the argument to see that it does in fact prompt currently). Joel
