Thanks, Mike,I'll take a look at your OpenID code and see what I can find. I
had just started looking into CAS SSO + AngularJS to see if anyone had done
that, so maybe between your code and the results I found for CASified AngularJS
apps I'll be able to get something working.
Thanks for the hints.
-Nick
On Tuesday, December 20, 2016 2:19 PM, Mike Jumper
<[email protected]> wrote:
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
