You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@guacamole.apache.org by "Nick Couchman (JIRA)" <ji...@apache.org> on 2018/02/01 04:17:00 UTC
[jira] [Comment Edited] (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=16347706#comment-16347706 ]
Nick Couchman edited comment on GUACAMOLE-197 at 2/1/18 4:16 AM:
-----------------------------------------------------------------
{quote}
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]:
{quote}
Yeah, I saw this and had it on my list to look at...
{quote}
Is the expectation of the state value that it is an opaque, binary value with no known encoding?
{quote}
I'm not entirely certain. I don't know that it actually matters much, so long as the client returns the same value to the server. The specification for the state field is found here:
[https://tools.ietf.org/html/rfc2865#section-5.24]
The only thing that seems to indicate anything to that end is the following statement: {quote}In either usage, the client MUST NOT interpret the attribute locally.{quote}This would indicate to me that we should probably try to keep it unencoded. I do remember early on in trying to implement this that I had quite a time getting the value out in the correct format and not mangle it in the process of passing it between the browser, the Guacamole code, and the RADIUS server. Looks like I'll be doing a little more playing around with that :).
{quote}
...
I doubt the state value will match what was originally received in the challenge request.
{quote}
So, in its currently implementation, it works as expected - the state value is passed from the RADIUS server into the authentication extension, then to the browser, then back to the extension and to the RADIUS server, and it seems to maintain a value expected by the RADIUS server in order to continue the authentication process. At least, I'm able to successfully do Challenge/Response authentication with this extension, FreeRADIUS, and LinOTP. I'm not sure if that's what you're asking, but, if the question is (simplified), "Does this actually work today?, " then the answer is "yes."
That said, I've tested it in a pretty specific environment with a pretty specific RADIUS server, so it's conceivable that what I'm doing just happens to work with FreeRADIUS + LinOTP and that some other RADIUS server (Microsoft, Cisco, etc.) will break. I might see if I can find another RADIUS implementation and try it out.
was (Author: nick.couchman@yahoo.com):
{quote}
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]:
{quote}
Yeah, I saw this and had it on my list to look at...
{quote}
Is the expectation of the state value that it is an opaque, binary value with no known encoding?
{quote}
I'm not entirely certain. I don't know that it actually matters much, so long as the client returns the same value to the server. The specification for the state field is found here:
[https://tools.ietf.org/html/rfc2865#section-5.24]
The only thing that seems to indicate anything to that end is the following statement: \{quote}In either usage, the client MUST NOT interpret the attribute locally.\{quote} This would indicate to me that we should probably try to keep it unencoded. I do remember early on in trying to implement this that I had quite a time getting the value out in the correct format and not mangle it in the process of passing it between the browser, the Guacamole code, and the RADIUS server. Looks like I'll be doing a little more playing around with that :).
{quote}
...
I doubt the state value will match what was originally received in the challenge request.
{quote}
So, in its currently implementation, it works as expected - the state value is passed from the RADIUS server into the authentication extension, then to the browser, then back to the extension and to the RADIUS server, and it seems to maintain a value expected by the RADIUS server in order to continue the authentication process. At least, I'm able to successfully do Challenge/Response authentication with this extension, FreeRADIUS, and LinOTP. I'm not sure if that's what you're asking, but, if the question is (simplified), "Does this actually work today?, " then the answer is "yes."
That said, I've tested it in a pretty specific environment with a pretty specific RADIUS server, so it's conceivable that what I'm doing just happens to work with FreeRADIUS + LinOTP and that some other RADIUS server (Microsoft, Cisco, etc.) will break. I might see if I can find another RADIUS implementation and try it out.
> 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)