Fallback to another SASL client mechanism when SASL client initialisation fails ------------------------------------------------------------------------------- Key: ELY-1682 URL: https://issues.jboss.org/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.10.1.CR1 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}