guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Jumper <mike.jum...@guac-dev.org>
Subject Re: Handling a SAML POST response
Date Fri, 22 Sep 2017 22:26:12 GMT
On Fri, Sep 22, 2017 at 2:39 PM, Colin McGuigan <
colin_guacamole@walkingshadows.org> wrote:

> tldr: The SAML POST body is getting thrown away, and I don't know how to
> keep
> that from happening.
>
> Longer: I'm writing a SAML authentication extension, based off of Mike
> Jumper's OpenID extension:
> https://github.com/mike-jumper/guacamole-auth-openid
>
>
FYI - that code is missing recent changes, as I moved things over to the
"openid-auth" branch of my development fork of incubator-guacamole-client,
to prepare things to be merged into mainline:

https://github.com/mike-jumper/incubator-guacamole-client/tree/openid-auth

...
> 5. Identity provider redirects user back to guacamole site
> (<site>/?id_token=...)
> 6. Javascript detects id_token, redirects user again
> (<site>/#/id_token=...)
> (I don't fully understand the point of this step, but not relevant to my
> actual question)
>

With OpenID Connect's "implicit flow" (which is what the
guacamole-auth-openid extension implements), the IDP sends the token back
within the URL fragment, with that token intended to be handled by
client-side code. The Guacamole extension manually rearranges that token
such that Guacamole's existing automatic authentication code will forward
it along to the authentication service for server-side verification and
handling.

OpenID Connect also provides a different flow which involves a POST to a
defined service, but Guacamole's authentication system doesn't work this
way. There is a .../api/tokens REST service which produces a JSON response
containing the auth token to be used for all future requests. POSTing to
that service would result in the generation of an auth token, but would not
result in the user being redirected back to Guacamole.


> ... Now on my SAML extension, step 1-4 are conceptually the same, and work
> fine.
> Step 5 is where things break down.  The IDP isn't sending information back
> in the URL, as is done with the id_token request parameter -- instead, it's
> a POST with the SAMLRequest data in the request body.  I see this POST
> going
> to the guacamole site.
>
> However, when it hits the extension, the request body is empty, which is
> not
> what I want -- I want the SAMLRequest body that the IDP sent.
>
>
The POST is not hitting the extension; it's hitting a static file.

I /presume/ that what is happening is that client-side Javascript is
> executing a separate POST to guacamole/api/tokens, and that it is this
> request that is actually being handled by the authentication extension.
> However, this request does not contain the original request body, hence, my
> problem.
>
>
Yes, this is exactly what is happening. The URL that the IDP is using is
not a service (it's static HTML and JavaScript), and the JavaScript will
not be able to see the body of that POST.

I see two possibilities:

1) Reconfigure things with the IDP such that the necessary token is
included in the URL, ideally via normal query parameters. Guacamole will
forward these automatically, and your extension will receive them in the
authentication request. Not sure whether this is possible with SAML.

2) Add a custom REST service within your extension that can accept the POST
and deal with the SAML body, generating some unique temporary token and
redirecting the user back to the main Guacamole page, including the token
in the URL. When the user is taken to that URL in their browser, Guacamole
will automatically send the token within the URL through the authentication
system, and your extension can validate and complete the process.

- Mike

Mime
View raw message