[
https://issues.apache.org/jira/browse/GUACAMOLE-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16263842#comment-16263842
]
Michael Jumper edited comment on GUACAMOLE-96 at 11/23/17 5:38 AM:
-------------------------------------------------------------------
I now have this working. Overall, there are several major changes involved:
* Modifications to the extension API which allow extensions to augment data
from other extensions (a {{decorate()}} function which is invoked for each
{{AuthenticationProvider}} to allow it to decorate the {{UserContext}} of
another).
* Modifications to the semantics of {{getAttributes()}} and {{setAttributes()}}
which allow extensions to (1) collaborate to store attributes which are added
externally by other extensions and (2) detect whether another extension allows
this.
* Corresponding enhancements to the database auth which allow other extensions
to leverage it for arbitrary storage of data related to an existing user,
connection, connection group, or sharing profile.
* ... the actual extension implementing TOTP (the standard Google Authenticator
uses): "guacamole-auth-totp"
When the TOTP extension (and database auth) are installed, users are required
to enroll an authentication device upon successful login:
{panel}
!guacamole-auth-totp-01-enroll.png!
{panel}
Once the user has confirmed that they can generate correct authentication
codes, they are allowed access to Guacamole. For all future logins, the user is
prompted for their authentication code directly:
{panel}
!guacamole-auth-totp-02-verify.png!
{panel}
The configurable aspects of TOTP can be set with properties in
{{guacamole.properties}}, but the defaults are those which are compatible with
Google Authenticator, so it should work out-of-the-box.
was (Author: mike.jumper):
I now have this working. Overall, there are several major changes involved:
* Modifications to the extension API which allow extensions to augment data
from other extensions (a {{decorate()}} function which is invoked for each
{{AuthenticationProvider}} to allow it to decorate the {{UserContext}} of
another).
* Modifications to the semantics of {{getAttributes()}} and {{setAttributes()}}
which allow extensions to (1) collaborate to store attributes which are added
externally by other extensions and (2) detect whether another extension allows
this.
* Corresponding enhancements to the database auth which allow other extensions
to leverage it for arbitrary storage of data related to an existing user,
connection, connection group, or sharing profile.
* ... the actual extension implementing TOTP (the standard Google Authenticator
uses): "guacamole-auth-totp"
When the TOTP extension (and database auth) are installed, users are required
to enroll an authentication device upon successful login:
!guacamole-auth-totp-01-enroll.png!
Once the user has confirmed that they can generate correct authentication
codes, they are allowed access to Guacamole. For all future logins, the user is
prompted for their authentication code directly:
!guacamole-auth-totp-02-verify.png!
The configurable aspects of TOTP can be set with properties in
{{guacamole.properties}}, but the defaults are those which are compatible with
Google Authenticator, so it should work out-of-the-box.
> Two factor authentication with Google Authenticator
> ---------------------------------------------------
>
> Key: GUACAMOLE-96
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-96
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client
> Reporter: L.J. van Ruiten
> Assignee: Michael Jumper
> Priority: Trivial
> Attachments: guacamole-auth-totp-01-enroll.png,
> guacamole-auth-totp-02-verify.png
>
>
> We have a few critical systems that are accessible through Guacamole and we
> have had some clients requesting a safer way to login. Two factor
> authentication is probably the best and easiest way to improve on the current
> username/password login, and I can imagine that this is something that other
> companies using Guacamole would also be interesting in this feature.
> I already did some tinkering myself and I found that Google Auhtenticator is
> simple to use, does not require any configuration (like you would with SMS
> codes) easy to implement and the "client" side of the authentication (the
> part that generates the codes) is easily integrated into existing apps.
> So far I have got Google Authenticator "kinda working". What I did is:
> - Started with guacamole-auth-jdbc as base
> - Added a secret key to a user account that is randomly generated upon
> creation. Also added a boolean field to indicate wether TFA is required for
> loggin in.
> - Used the GuacamoleInsufficientCredentialsException to redirect the user the
> a second screen asking for a TFA code after loggin in with the username and
> password.
> However as said before this only "kinda works" because:
> I have only gotten the TFA enable button to appear in the user's managing
> page, so it can only be enabled by administrators and that's also where I put
> the secret key shows up, so users can't find it themself.
> For as far as I could find the previous point cannot be done with just the
> guacamole-ext api. Even with the new API that enables you to insert HTML
> parts, you would also need an API endpoint to provide the secret key or
> ideally generate a QR code that Google Auhtenticator can read to bind a
> device to the account (I would like it to appear in the user's preference
> page).
> So in summary if other people are interested I would be willing to contribute
> this, but I would need some directions and I have a few questions:
> - Am I right that it is currently not possible to add an API endpoint just
> using guacamole-ext to provide the QR codes?
> - What would be the way to implement this? Personally I thought that adding
> these options to the user's page would be the easiest.
> - Is this a feature you would like me to work on and contribute?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
