guacamole-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Couchman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
Date Mon, 05 Jun 2017 19:12:04 GMT

    [ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037421#comment-16037421
] 

Nick Couchman commented on GUACAMOLE-197:
-----------------------------------------

{quote}
Hello, I love that Guacamole is including RADIUS auth. I routinely use OpenOTP as a 2factor
RADIUS server, and enabling Guacamole as a RADIUS client will make it eminently more useful
for my purposes.
{quote}

Glad to hear I'm not the only one interested in it.

{quote}
One additional feature I hope this project may consider adding is the ability to filter which
configuration a user has access to upon authentication. With LDAP, Guacamole has the ability
to provide a user access to a configuration based on which LDAP group the user is a member
of (see here https://guacamole.incubator.apache.org/doc/0.9.3/gug/ldap-auth.html). This can
be done with RADIUS as well, but requires the RADIUS client implementation to "look" at attributes
that are returned by the RADIUS server.
{quote}

I have plans (in my head, anyway) to expand RADIUS support in Guacamole later on for both
authorization and accounting features, which I think would cover what you're talking about,
here.  At the moment, this extension only does authentication and relies on other stacked
authentication modules to provide the actual connection information.  The feature that you're
referencing in the LDAP Authentication module works when the connections are stored in LDAP,
and the LDAP directory is used for both authentication and connection information.  If you
layer LDAP with DB, you're left with the same challenge - the connections in the DB layer
must be managed apart from the directory tree.

I think there's also a JIRA issue opened at the moment to add group support to the Guacamole
client, which would also probably address the challenges, here - I would image that would
also resolve the challenge you're facing of having to administer user/connection permissions
on an individual basis.  The combination of the two - groups in Guacamole and an improved
RADIUS module - is certainly an ideal place to get.

If you're able to contribute code to the effort I'd welcome the contribution!

> Implement Support for RADIUS Authentication
> -------------------------------------------
>
>                 Key: GUACAMOLE-197
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-197
>             Project: Guacamole
>          Issue Type: Improvement
>          Components: guacamole, guacamole-client
>            Reporter: Nick Couchman
>            Assignee: Nick Couchman
>            Priority: Minor
>             Fix For: 0.9.14-incubating
>
>
> Working on implementing a RADIUS authentication module - guacamole-auth-radius.  The
basic implementation is completed - with a basic PAP or CHAP RADIUS server, the authentication
succeeds and the user is logged in.
> I'm running into an issue, though, trying to implement Challenge/Response in RADIUS.
 I have my RADIUS server configured to talk to LinOTP for MFA/2FA, and RADIUS sends the AccessChallenge
package back, asking for the second factor.  My issue is in my continual failure to grasp
the connection between the servlet side and the AngularJS web application.  I've copied the
Duo authentication code and tried to morph it into something that will present another box
for the RADIUS challenge, but I can't get my controller function to actually fire.
> Once that is working, I'd like to support other RADIUS authentication protocols, like
EAP-TLS and EAP-TTLS, so there's a little more work to be done, but right now I'm focusing
on the basic protocols and the challenge/response.
> Will have a repo posted here in a moment for working on this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message