I wouldn't recommend trying to alter the web.xml, nor trying to use JSP. There must be a better way.
I'm not familiar with CAS SSO myself, but I did write a proof-of-concept OpenID authentication extension for Guacamole which involves a similar flow (redirect to third-party site, redirect back): https://github.com/mike-jumper/guacamole-auth-openid The implementation hinged on defining a custom field type which the auth provider could specify when requesting additional credentials: https://github.com/mike-jumper/guacamole-auth-openid/blob/348151bd299617e21840a5d526af150016fdcbec/src/main/java/org/glyptodon/guacamole/auth/oauth/form/OAuthTokenField.java https://github.com/mike-jumper/guacamole-auth-openid/blob/348151bd299617e21840a5d526af150016fdcbec/src/main/java/org/glyptodon/guacamole/auth/oauth/AuthenticationProviderService.java#L107-L120 The field is written to redirect the user appropriately: https://github.com/mike-jumper/guacamole-auth-openid/blob/348151bd299617e21840a5d526af150016fdcbec/src/main/resources/oauthConfig.js https://github.com/mike-jumper/guacamole-auth-openid/blob/348151bd299617e21840a5d526af150016fdcbec/src/main/resources/oauthController.js The abstract concept here is: 1) User visits Guacamole, but is not authenticated. 2) The auth provider requests the credentials it needs, in this case a validation token from the SSO service. A field type is defined which represents this token. 3) The field type implementation performs the client-side tasks necessary to retrieve that token, in this case redirecting the user. 4) The SSO service authenticates the user, produces the token, and sends the user back to the original site. 5) The field implementation retrieves the token and forwards it along as the user's credentials. 6) Authentication succeeds. Perhaps something like that would work in your case? - Mike On Tue, Dec 20, 2016 at 9:43 AM, <[email protected]> wrote: > So, just as a follow-up to this...I looked into a couple of other > possibilities, but am having trouble making any of them work:- > web-fragment.xml, a way to add stuff to web.xml without having it actually > in web.xml. This looked really promising at first, but it seems that > anything JAR file providing web-fragment.xml files must be located in the > WEB-INF/lib directory, and since Guacamole loads authentication extensions > from GUACAMOLE_HOME/extensions, this doesn't seem to work.- Creating an > implementation of ServletContextListener and then using the programmatic > options to add filters to a servlet. The problem here - the class > implementing ServletContextListener has to be listed in the web.xml file > (or, presumably, web-fragment.xml), which makes implementing this as an > extension difficult.- Some sort of Guice implementation that uses the above > method of implementing a ServletContextListener and then binding it to a > class already implemented in the main Guacamole code. Unfortunately it > doesn't appear (to me) that there's anything existing that a class like > this would bind to, which means modification to the existing client code > before such an extension would actually work.- Figure out a way to > implement the logon redirection to CAS SSO in JSP rather than using > filters. I'm still working this angle, just don't know how possible it > actually is. > Other ideas? Anything I'm missing here? > -Nick > > On Monday, December 19, 2016 5:51 PM, "[email protected]" < > [email protected]> wrote: > > > > Hello, everyone,I've started attempting to write an authentication module > for Guacamole that integrates with the Apereo CAS SSO product. I know a > person or two has already attempted this, but I haven't seen anyone's code, > so I'm starting from scratch. I'm struggling a little with how this should > integrate with the existing Guacamole web client. In the current client, > it seems like the client displays the normal username/password box, and > credentials are then passed back to one or more backend authentication > classes. In implementing a CAS SSO module, instead of displaying the login > box, the page needs to redirect to the SSO login page, which either > displays the credential prompt or returns an already active SSO session. > In doing some research, it looks as if the preferred method of > accomplishing this with the CAS SSO Java client is via modifications to the > web.xml file - adding login filters to that. I'm not entirely sure if this > is "compatible" with how extensions are currently implemented in the > Guacamole web client - if there's any way to have an extension add to the > web.xml file? I've managed to get SSO to work (mostly) by manually adding > these filters to the web.xml and then writing a very basic authentication > extension that grabs the username from the HTTP session and returns an > empty <String, GuacamoleConfiguration> map. It's a work in progress :-). > So, my first question is, is there a different way i should be going about > having the existing Guacamole web client bypass the username/password > dialog and redirect to the SSO login page? If the web.xml file is the > preferred way, is there a way I should go about overriding the existing one > via an extension? > Second, for the extension class for the backend portion of the > authentication, is there something more secure I should be doing with the > SSO stuff than just grabbing the current session username - trying to get > and verify the ticket or something like that? Or is this good enough given > that the login page redirects to SSO? > Thanks, and go easy on a newbie Guac/Java developer :-). > -Nick > > > >
