Nick, Thanks for pointing this issue out to me! I have started looking over the pull requests and I am going to try and test your changes in my test environment here. Hopefully I will be able to get you some feedback soon.
Tim On Wed, Apr 22, 2020 at 3:30 PM Nick Couchman <[email protected]> wrote: > On Wed, Apr 22, 2020 at 1:04 PM Tim Worcester <[email protected] > > > wrote: > > > Greetings, > > > > Apologies this message is a duplicate of: > > > > > http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/v1-1-0-OpenID-and-RDP-connection-password-td8081.html > > A colleague recommended I drop this in the contributor mailing list > instead > > of the general users one. > > > > I currently have my guacamole client v1.1.0 configured to point to > Keycloak > > using the OIDC configuration options. This is causing my login > information > > to > > be passed through Keycloak instead of the Guacamole Client login page. > > Because of this the GUAC_PASSWORD parameter is never populated because it > > was never actually input through Guacamole itself. > > > > > Yep, this is pretty common among SSO extensions. The only exception is > CAS, which has the ClearPass extensions available that can actually make > the password available. > > > > I am trying to put a user prompt in the UI to have them input their > > password > > when clicking an 'rdp' protocol connection. Currently I have a prompt > hook > > in > > ManagedClient.js that sends the password to the TokenRESTService and > calls: > > > > final Credentials credentials = authenticatedUser.getCredentials(); > > credentials.setPassword(password); > > // Should call update user credentials (private method in authService) > > authenticationService.authenticate(credentials, token); > > > > My connection parameters are setup to use ${GUAC_USERNAME} and > > ${GUAC_PASSWORD} but the above code doesn't seem to update > ${GUAC_PASSWORD} > > or the current sessions Authenticated User object. > > > > > Yeah, if the authenticate() function has already fired to authenticate the > user via SSO, then I'm not sure the above code would work to set the > password for the session. The tokens get extracted and configured in a > certain order, too, so it's possible that, even if the above the call > actually succeeds in setting the password value, the tokens won't actually > update. > > I'm not certain this will work, but you might just try looking and making > sure your call to update the password value happens prior to the actual > connection starting, and prior to the tokens being extracted during the > connection process. > > > > My two main questions are: > > 1) Is there a configuration option that I am missing that covers this use > > case? > > > > Not, yet. It is covered under this JIRA issue: > https://issues.apache.org/jira/browse/GUACAMOLE-221 > > and there are a couple of pull requests open for it: > https://github.com/apache/guacamole-client/pull/430 > https://github.com/apache/guacamole-server/pull/228 > > Unfortunately these still need some review and work prior to merging them > into the code, so they aren't quite ready, yet. > > 2) What step am I missing to have the java services update ${GUAC_PASSWORD} > > properly? > > > > > It actually seems like it might be better to write a custom authentication > extensions that prompts the user for this value at login time and stores it > in a custom token that you could use in the connection process. Of course, > this kind of defeats the purpose of using SSO to begin with, so it seems a > little counter-productive, but if you really need it prior to the official > prompting support being available in the code, then that might be the way > to go. > > -Nick >
