We're updating the issue view to help you get more done. 

CAS server webapp fails to instantiate a EAPTTLSAuthenticator for each authentication request

Description

Attempting to use EAP-TTLS for RADIUS authentication through CAS fails. We've tracked it down to the fact that each authentication request should start a new instance of the EAP-TTLS authenticator (net.jradius.client.auth.EAPTTLSAuthenticator), since every EAP-TTLS session is unique.

Alan DeKok from FreeRADIUS agrees that the EAP-TTLS conversation keeps resending the first authentication credentials, which is incorrect, and David Bird from Coova (maintainer of JRadius) agrees with him. David says that the EAPTTLSAuthenticator must be reinstantiated every time. I suspect this may be the case for ALL EAP authentication mechanisms, but I can't find anything substantial online that supports that hypothesis because it appears that there's virtually no-one using the EAPTTLSAuthenticator with CAS.

To fix this, JRadiusServerImpl.java specifically needs to change to create a new instance of this.radiusAuthenticator in every authenticate() call. I've made this basic change:

Class <?> c = this.radiusAuthenticator.getClass();
RadiusAuthenticator thisAuth = null;
try
{ thisAuth = (RadiusAuthenticator)c.newInstance(); }
catch(Exception e)
{ LOG.error("Unable to create new instance of authenticator", e); thisAuth = this.radiusAuthenticator; }
RadiusPacket response = radiusClient.authenticate(request, thisAuth, this.retries);

No doubt this can be improved significantly, probably by calling this.radiusAuthenticator.getAuthName() and checking if the authenticator starts with "eap-" since this is particularly essential for EAP authentication sessions.

Environment

CentOS 6.4, Tomcat v6, CAS v3.5.2 with JRadius Extended Client v1.1.4 (for PEAP, EAP-TLS and EAP-TTLS support).

Status

Assignee

Marvin Addison

Reporter

Stefan Paetow

Labels

None

Estimated End Date

None

Audience

None

Components

Fix versions

Affects versions

3.5.2

Priority

Major