On Mon, Mar 4, 2019 at 7:16 PM Lee <[email protected]> wrote: > Mike, thank you for your feedback. I've forwarded that onto my teammates to > look into. I agree, I'd prefer to not go in a route that is going to be > constantly against the design of Guacamole, and the links you provide might > be a great alternative I did not see while looking at the > SimpleAuthenticationProvider code. If that ANONYMOUS_IDENTIFIER pathway > allows a second session without re-using the existing one, that would > probably be a perfect work-around to the problem. If that isn't quite > right, > I'll explore the extension API options. > > Based on what you've said in your other thread, it does sound like you're fighting the interface rather than working with it :-).
One thing that is worth noting is that Guacamole does create persistent URLs for connections within the interface - so, when you see something like: https://guacamole.example.com/guacamole/#/client/MzkAYwBwb3N0Z3Jlc3Fs The end part of it (/client/MzkAYwBwb3N0Z3Jlc3Fs) will always take you to the same connection, because it encodes the connection type (connection or connection group), the data source name, and the identifier, within that identifier. So, one idea would be to create links to these connections (on a home page or separate page somewhere) and then use some sort of SSO extension (CAS, OpenID, maybe Header) to log users in so that they could transparently open those connections. The connections could be stored in the JDBC module, stacked with a SSO module, so that permissions could be assigned within JDBC but still transparently log users in. Another idea would be to use the common Guacamole pieces (guacd, guacamole-common and guacamole-common-js) and build your own web application around the protocol and common components rather than trying to squeeze the full Guacamole Client into your environment, if it doesn't fit. -Nick
