[jboss-jira] [JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

[Darran Lofthouse (JIRA)]

     [ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1682:
----------------------------------
    Fix Version/s: 1.7.0.CR2


> 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
>             Fix For: 1.7.0.CR2
>
>         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}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)