]
Farah Juma updated ELY-1682:
----------------------------
Fix Version/s: 1.11.0.CR6
(was: 1.11.0.CR5)
Fallback to another SASL client mechanism when SASL client
initialisation fails
-------------------------------------------------------------------------------
Key: ELY-1682
URL:
https://issues.redhat.com/browse/ELY-1682
Project: WildFly Elytron
Issue Type: Bug
Components: SASL
Affects Versions: 1.7.0.CR1
Reporter: Martin Choma
Priority: Major
Fix For: 1.11.0.CR6
Attachments:
org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
{code:title=HipChat conversation}
Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and
PLAIN. Client has only username/password credential - no kerberos credential.
But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I
set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN"))
scenario works ok.
I wonder could Authentication Client be smart enough to not try to initialize
authentication mechanisms which it has not credentials for?
Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the
mech obtains from OS level. The mech should fail and allow the next mech to be selected
Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback
does not work properly. (At least in IBM JDK case).
In this case it is initialization of mechanism which is failing, so maybe fallback does
not have chance to get involved.
Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it
as a failed mech and move on - maybe something needed in Remoting
though for that one as that is where that loop happens but start with an ELY issue
{code}