You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@guacamole.apache.org by "Michael Jumper (JIRA)" <ji...@apache.org> on 2018/01/31 20:25:00 UTC

[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication

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

Michael Jumper commented on GUACAMOLE-197:
------------------------------------------

With the recent merge to master, FindBugs is now reporting the following [dubious {{new String(byte\[\])}} call|https://github.com/apache/guacamole-client/blob/a050c1602033ee0b8303302e05530100faedb8d8/extensions/guacamole-auth-radius/src/main/java/org/apache/guacamole/auth/radius/AuthenticationProviderService.java#L100]:

{code:none}
String radiusState = new String(stateAttr.getValue().getBytes());
{code}

(See http://findbugs.sourceforge.net/bugDescriptions.html#DM_DEFAULT_ENCODING)

Rereading through this and the surrounding code to figure out the original intent, I end up wondering:

# Is the expectation of the state value that it is an opaque, binary value with no known encoding? If so, then it should be transmitted in some way that preserves the binary value (base64 or hex come to mind), rather than being decoded to the platform default encoding, UTF-8, etc.
# When this value is received as the client responds to the challenge, the string value of the parameter is simply given to the constructor of {{Attr_State}}, which accepts any {{Serializable}}. Is it known what this will actually do? If {{Attr_State}} is using Java's built-in serialization to turn that {{String}} back into a {{byte[]}}, I doubt the state value will match what was originally received in the challenge request.

Any ideas?

> 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: 1.0.0
>
>
> 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
(v7.6.3#76005)