[
https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s...
]
David Lloyd commented on ELY-1682:
----------------------------------
The aggregate SaslClientFactory does not have any practical recourse for failing to
construct a SaslClient, as the caller cannot really know which one failed. The
SaslClientFactory interface accepts a list of candidate mechanisms and then returns an
instance using one of those mechanisms.
One possible solution is to modify our SASL client implementations to not fail on
construction, but instead defer failure to the first negotiation step. This could easily
be done by defining and returning a {{FailedSaslClient}} which is initialized with the
mechanism name.
In addition, factories acquired from external providers could possibly be (individually)
wrapped so that a failure on construction can be caught and wrapped as well.
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
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)