guacamole-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jumper (JIRA)" <>
Subject [jira] [Commented] (GUACAMOLE-210) OAuth2 authentication plugin
Date Tue, 06 Jun 2017 21:11:18 GMT


Michael Jumper commented on GUACAMOLE-210:

It might make sense to do something similar to guacamole-auth-jdbc-*, where there is a common
base shared by the similar extensions, with a single manual chapter covering its use. Restructuring
the projects that way would only make sense if there's enough overlap in the internal structure
of the extensions, though. In the case of the database auth, this was a pretty easy choice
to make since the extensions are identical in every way except for the database being used.
Not sure how clear-cut this is for SSO.

Even if there isn't enough overlap that sharing a common base would be sensible, it may still
make sense to combine the documentation into a single SSO chapter.

In either case, my $0.02 is there should still be separate extensions for each. A single,
monolithic, SSO swiss army knife would be difficult to maintain as it grows, not to mention
separation of concerns.

> OAuth2 authentication plugin
> ----------------------------
>                 Key: GUACAMOLE-210
>                 URL:
>             Project: Guacamole
>          Issue Type: New Feature
>          Components: guacamole-client
>            Reporter: Michael Jumper
>            Assignee: Michael Jumper
> {panel:bgColor=#FFFFEE}
> *The description of this issue was copied from [GUAC-1485|],
an issue in the JIRA instance used by the Guacamole project prior to its acceptance into the
Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance *have not
been copied* and can be found instead at the original issue.
> {panel}
> It would be nice if Guacamole had OAuth2 authentication plugin.
> OAuth2 is wide spread in web technologies and Guacamole deserves to have its implementation
of the protocol.
> My company had this use case and for now we are using a custom authentication plugin
because implementing a generic OAuth2 compatible Guacamole authentication plugin presents
some difficulties.
> h1. RedirectURI doesn't work because of Angular anchor system
> OAuth2 requires clients (Guacamole in our case) to register a redirect URI so that the
OAuth2 server could callback the application when the user has been identify (or rejected)
on its side. It also passes along some informations like tokens or reason of failure as part
of the URL. If we set the Guacamole index URL as the redirect URI then this data never get
passed along to the authenticate plugin.
> Such redirect URI cannot contain any pound sign (#) because this sign in a URI is a delimiter
after which data are not sent to the server on HTTP request. In the case of Guacamole, the
Angular frontend uses those local URI data to determine which page to display.
> Angular behavior cannot be easilly turned off and would lead to heaver code changes and
uncompatibility with older browser.
> h1. Retrieve to connection list on authentication
> Connection list is retrieved at user login. It doesn't make sense to expect the OAuth
server to give such list as it would not be generic enough.
> Fortunatly, connection lists get merged between authentication plugins and this OAuth
plugin could be paired with another one which goal would just be to provide the connection
> h1. Token invalidation
> Upon a successful authentication, the OAuth2 server will issued an auth token.
> First, this token needs to be invalidated by Guacamole when user explicitly disconnects.
> Second, there is no way for Guacamole to know if a stored auth token is still valid.
Leaving the user to freely keep on using its Guacamole session even thought the token has
> I am just leaving these though here so the Guacamole community could start an discussion
on this matter.

This message was sent by Atlassian JIRA

View raw message