Mailing-List: contact user-help@guacamole.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@guacamole.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <1506116383746-0.post@n4.nabble.com>
References: <1506116383746-0.post@n4.nabble.com>
From: Mike Jumper <mike.jumper@guac-dev.org>
Date: Fri, 22 Sep 2017 15:26:12 -0700
Message-ID: <CALKeL-PT3zi0mv6efSkouvPujUEHeMYn4PQqgUhz7aZ0a5x=+g@mail.gmail.com>
Subject: Re: Handling a SAML POST response
To: user@guacamole.incubator.apache.org
Content-Type: multipart/alternative; boundary="94eb2c1b047ea80b4b0559ceb453"
archived-at: Fri, 22 Sep 2017 22:27:00 -0000

--94eb2c1b047ea80b4b0559ceb453
Content-Type: text/plain; charset="UTF-8"

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

--94eb2c1b047ea80b4b0559ceb453
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 22, 2017 at 2:39 PM, Colin McGuigan <span dir=3D"ltr">&lt;<a href=
=3D"mailto:colin_guacamole@walkingshadows.org" target=3D"_blank">colin_guac=
amole@walkingshadows.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">tldr: The SAML POST body is getting thrown away, a=
nd I don&#39;t know how to keep<br>
that from happening.<br>
<br>
Longer: I&#39;m writing a SAML authentication extension, based off of Mike<=
br>
Jumper&#39;s OpenID extension:<br>
<a href=3D"https://github.com/mike-jumper/guacamole-auth-openid" rel=3D"nor=
eferrer" target=3D"_blank">https://github.com/mike-<wbr>jumper/guacamole-au=
th-openid</a><br>
<br></blockquote><div><br></div><div>FYI - that code is missing recent chan=
ges, as I moved things over to the &quot;openid-auth&quot; branch of my dev=
elopment fork of incubator-guacamole-client, to prepare things to be merged=
 into mainline:</div><div><br></div><div><a href=3D"https://github.com/mike=
-jumper/incubator-guacamole-client/tree/openid-auth">https://github.com/mik=
e-jumper/incubator-guacamole-client/tree/openid-auth</a><br></div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">...<br>
5. Identity provider redirects user back to guacamole site<br>
(&lt;site&gt;/?id_token=3D...)<br>
6. Javascript detects id_token, redirects user again (&lt;site&gt;/#/id_tok=
en=3D...)<br>
(I don&#39;t fully understand the point of this step, but not relevant to m=
y<br>
actual question)<br></blockquote><div><br></div><div>With OpenID Connect=
9;s &quot;implicit flow&quot; (which is what the guacamole-auth-openid exte=
nsion implements), the IDP sends the token back within the URL fragment, wi=
th that token intended to be handled by client-side code. The Guacamole ext=
ension manually rearranges that token such that Guacamole&#39;s existing au=
tomatic authentication code will forward it along to the authentication ser=
vice for server-side verification and handling.</div><div><br></div><div>Op=
enID Connect also provides a different flow which involves a POST to a defi=
ned service, but Guacamole&#39;s authentication system doesn&#39;t work thi=
s way. There is a .../api/tokens REST service which produces a JSON respons=
e 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.</div><div>=C2=A0<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">... Now on my SAML=
 extension, step 1-4 are conceptually the same, and work fine.<br>
Step 5 is where things break down.=C2=A0 The IDP isn&#39;t sending informat=
ion back<br>
in the URL, as is done with the id_token request parameter -- instead, it&#=
39;s<br>
a POST with the SAMLRequest data in the request body.=C2=A0 I see this POST=
 going<br>
to the guacamole site.<br>
<br>
However, when it hits the extension, the request body is empty, which is no=
t<br>
what I want -- I want the SAMLRequest body that the IDP sent.<br>
<br></blockquote><div><br></div><div>The POST is not hitting the extension;=
 it&#39;s hitting a static file.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
I /presume/ that what is happening is that client-side Javascript is<br>
executing a separate POST to guacamole/api/tokens, and that it is this<br>
request that is actually being handled by the authentication extension.<br>
However, this request does not contain the original request body, hence, my=
<br>
problem.<br>
<br></blockquote><div><br></div><div>Yes, this is exactly what is happening=
. The URL that the IDP is using is not a service (it&#39;s static HTML and =
JavaScript), and the JavaScript will not be able to see the body of that PO=
ST.</div><div><br></div><div>I see two possibilities:</div><div><br></div><=
div>1) Reconfigure things with the IDP such that the necessary token is inc=
luded in the URL, ideally via normal query parameters. Guacamole will forwa=
rd these automatically, and your extension will receive them in the authent=
ication request. Not sure whether this is possible with SAML.</div><div><br=
></div><div>2) Add a custom REST service within your extension that can acc=
ept the POST and deal with the SAML body, generating some unique temporary =
token and redirecting the user back to the main Guacamole page, including t=
he token in the URL. When the user is taken to that URL in their browser, G=
uacamole will automatically send the token within the URL through the authe=
ntication system, and your extension can validate and complete the process.=
</div><div><br></div><div>- Mike</div><div><br></div></div></div></div>

--94eb2c1b047ea80b4b0559ceb453--