Console ID Cache issue when using user-mapping.xml

[Rishi <2r...@gmail.com>]

Hello All,

I'm using guacamole in an automated fashion such that after completing the
external authentication, a new user-mapping.xml is generated.

The guacamole authentication in this case works correct however websocket
connection for console happens to the last consoled vm. It is not able to
properly disconnect last websocket session upon generation of new
user-mapping.xml. I suspect its the cookies !

If a new browser is used then the problem does not seem to appear.

So, would like to know how can I force flush cookies (if thats the problem)
whenever guacamole UI is reloaded ?

Regards,
Rishi

Re: Console ID Cache issue when using user-mapping.xml

[Mike Jumper <mi...@guac-dev.org>]

On Fri, Oct 21, 2016 at 2:56 AM, Rishi <2r...@gmail.com> wrote:

> Hi Mike,
>
> I did wrote a separate authentication module inspired from noauth however
> the problem still persists.
> It is the cookie that connects to original console and not new one. If I
> remove cookie and try for new console, it works fine.
>
>
Authentication/session state is tied to the authentication token, which is
stored in memory and, yes, within a cookie by JavaScript. The cookie is not
used in the traditional sense, and is ignored by the server. The part of
HTTP requests which the web application uses to tie a request to a session
is the "token" parameter.

Any ideas how can I force flush cookie and let it go through authentication
> module ?
>
>
First, to clarify, I think it's important to avoid fixating on the cookie.
While it is part of the issue you're encountering, it is not actually the
cause. Both the built-in extension which uses user-mapping.xml and the
NoAuth extension cache the connections available to a user, so if you're
basing your authentication extension on NoAuth, there is a good chance you
inherited that behavior. The caching is internal to
SimpleAuthenticationProvider.

If you implement AuthenticationProvider directly, rather than using the
SimpleAuthenticationProvider class, the level of caching (if any) can be
dictated by your implementation.

Beyond that, if you find yourself fighting the authentication/extension
subsystem, you might want to look into integrating the core of Guacamole
rather than the entire web application. The authentication system is
specific to the web application we wrote around our own APIs, and those
APIs are intentionally kept independent. If you integrate the remote
desktop functionality of Guacamole using those APIs, then you can dictate
how connections are established entirely yourself:

http://guacamole.incubator.apache.org/doc/gug/writing-you-own-guacamole-app.html

- Mike

Re: Console ID Cache issue when using user-mapping.xml

[Rishi <2r...@gmail.com>]

Hi Mike,

I did wrote a separate authentication module inspired from noauth however
the problem still persists.
It is the cookie that connects to original console and not new one. If I
remove cookie and try for new console, it works fine.

Any ideas how can I force flush cookie and let it go through authentication
module ?

Regards,
Rishi


On Tue, Oct 18, 2016 at 1:55 PM, Rishi <2r...@gmail.com> wrote:

> Thanks Mike for detailed information and saving hours in pursuing wrong
> path.
>
> I'd definitely look into custom auth and build something for us.
> I'm simply looking for a web callback as authentication mechanism. Let me
> know if its already present while I proceed to develop one. And in case I'm
> getting it working, can I contribute it back ?
>
> - Rishi
>
> On Tue, Oct 18, 2016 at 3:54 AM, Mike Jumper <mi...@guac-dev.org>
> wrote:
>
>> On Tue, Oct 11, 2016 at 3:41 AM, Rishi <2r...@gmail.com> wrote:
>>
>>> Hello All,
>>>
>>>
>> Hello Rishi,
>>
>>
>>> I'm using guacamole in an automated fashion such that after completing
>>> the external authentication, a new user-mapping.xml is generated.
>>>
>>
>> The intended mechanism for integrating Guacamole with external
>> authentication is not through auto-generating XML, but rather through
>> extensions:
>>
>> http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html
>>
>> http://guacamole.incubator.apache.org/doc/gug/custom-auth.html
>>
>> More on this below.
>>
>> The guacamole authentication in this case works correct however websocket
>>> connection for console happens to the last consoled vm. It is not able to
>>> properly disconnect last websocket session upon generation of new
>>> user-mapping.xml. I suspect its the cookies !
>>>
>>>
>> Guacamole doesn't use cookies in this way, but the authentication
>> mechanism that uses user-mapping.xml will cache the connections available
>> to a particular user once they log in, associating that information with
>> their session from that point forward. They will not see the results of
>> changes to that file until after they log out (or until they log in
>> elsewhere).
>>
>> If a new browser is used then the problem does not seem to appear.
>>>
>>
>> Yep. See above.
>>
>>
>>> So, would like to know how can I force flush cookies (if thats the
>>> problem) whenever guacamole UI is reloaded ?
>>>
>>
>> I don't think you should continue pursuing a solution driven by
>> user-mapping.xml. That authentication method is intentionally simple, and
>> not intended to serve as the middle ground between Guacamole and an
>> external authentication system. It's really aimed at simple deployments, or
>> as a quick way to verify that Guacamole works as expected before moving on
>> to something like LDAP or a database.
>>
>> In your case, where the idea is to integrate Guacamole with an external
>> system, I highly recommend developing an extension which does so. Guacamole
>> provides an API to achieve exactly this, and it's how the other
>> authentication extensions were written. There's no need to hack things
>> together using XML as an intermediary.
>>
>> - Mike
>>
>>
>

Re: Console ID Cache issue when using user-mapping.xml

[Rishi <2r...@gmail.com>]

Thanks Mike for detailed information and saving hours in pursuing wrong
path.

I'd definitely look into custom auth and build something for us.
I'm simply looking for a web callback as authentication mechanism. Let me
know if its already present while I proceed to develop one. And in case I'm
getting it working, can I contribute it back ?

- Rishi

On Tue, Oct 18, 2016 at 3:54 AM, Mike Jumper <mi...@guac-dev.org>
wrote:

> On Tue, Oct 11, 2016 at 3:41 AM, Rishi <2r...@gmail.com> wrote:
>
>> Hello All,
>>
>>
> Hello Rishi,
>
>
>> I'm using guacamole in an automated fashion such that after completing
>> the external authentication, a new user-mapping.xml is generated.
>>
>
> The intended mechanism for integrating Guacamole with external
> authentication is not through auto-generating XML, but rather through
> extensions:
>
> http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html
>
> http://guacamole.incubator.apache.org/doc/gug/custom-auth.html
>
> More on this below.
>
> The guacamole authentication in this case works correct however websocket
>> connection for console happens to the last consoled vm. It is not able to
>> properly disconnect last websocket session upon generation of new
>> user-mapping.xml. I suspect its the cookies !
>>
>>
> Guacamole doesn't use cookies in this way, but the authentication
> mechanism that uses user-mapping.xml will cache the connections available
> to a particular user once they log in, associating that information with
> their session from that point forward. They will not see the results of
> changes to that file until after they log out (or until they log in
> elsewhere).
>
> If a new browser is used then the problem does not seem to appear.
>>
>
> Yep. See above.
>
>
>> So, would like to know how can I force flush cookies (if thats the
>> problem) whenever guacamole UI is reloaded ?
>>
>
> I don't think you should continue pursuing a solution driven by
> user-mapping.xml. That authentication method is intentionally simple, and
> not intended to serve as the middle ground between Guacamole and an
> external authentication system. It's really aimed at simple deployments, or
> as a quick way to verify that Guacamole works as expected before moving on
> to something like LDAP or a database.
>
> In your case, where the idea is to integrate Guacamole with an external
> system, I highly recommend developing an extension which does so. Guacamole
> provides an API to achieve exactly this, and it's how the other
> authentication extensions were written. There's no need to hack things
> together using XML as an intermediary.
>
> - Mike
>
>

Re: Console ID Cache issue when using user-mapping.xml

[Mike Jumper <mi...@guac-dev.org>]

On Tue, Oct 11, 2016 at 3:41 AM, Rishi <2r...@gmail.com> wrote:

> Hello All,
>
>
Hello Rishi,


> I'm using guacamole in an automated fashion such that after completing the
> external authentication, a new user-mapping.xml is generated.
>

The intended mechanism for integrating Guacamole with external
authentication is not through auto-generating XML, but rather through
extensions:

http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html

http://guacamole.incubator.apache.org/doc/gug/custom-auth.html

More on this below.

The guacamole authentication in this case works correct however websocket
> connection for console happens to the last consoled vm. It is not able to
> properly disconnect last websocket session upon generation of new
> user-mapping.xml. I suspect its the cookies !
>
>
Guacamole doesn't use cookies in this way, but the authentication mechanism
that uses user-mapping.xml will cache the connections available to a
particular user once they log in, associating that information with their
session from that point forward. They will not see the results of changes
to that file until after they log out (or until they log in elsewhere).

If a new browser is used then the problem does not seem to appear.
>

Yep. See above.


> So, would like to know how can I force flush cookies (if thats the
> problem) whenever guacamole UI is reloaded ?
>

I don't think you should continue pursuing a solution driven by
user-mapping.xml. That authentication method is intentionally simple, and
not intended to serve as the middle ground between Guacamole and an
external authentication system. It's really aimed at simple deployments, or
as a quick way to verify that Guacamole works as expected before moving on
to something like LDAP or a database.

In your case, where the idea is to integrate Guacamole with an external
system, I highly recommend developing an extension which does so. Guacamole
provides an API to achieve exactly this, and it's how the other
authentication extensions were written. There's no need to hack things
together using XML as an intermediary.

- Mike