[
https://issues.jboss.org/browse/ELY-374?page=com.atlassian.jira.plugin.sy...
]
David Lloyd edited comment on ELY-374 at 11/19/15 11:17 AM:
------------------------------------------------------------
Here are some options:
# Add a field to {{CredentialCallback}} to designate local or peer credential, or perhaps
client or server credential. In the Entity mechanism, use {{CredentialCallback}} on the
client and server to acquire the local credential to use, and the general peer trust
callback to verify the peer's public credential. On the client, only local
credentials may be sensibly acquired, but on the server, either local or peer credentials
might be acquired.
# Add a field to {{CredentialCallback}} as above, but stop using
{{VerifyPeerTrustedCallback}} to verify the client, instead using a second (peer)
{{CredentialCallback}} to acquire the user public credential and performing the validation
within the mechanism. The {{VerifyPeerTrustedCallback}} (or its ELY-373 equivalent) would
still be used on the client to verify the server.
# Add a {{LocalCredentialCallback}} which acquires the local credential. Use this
credential on the server to acquire the host credential. Change the client to use this
callback to acquire the user credential on the client. The server would continue to use
{{CredentialCallback}} to acquire the user (peer) credential.
# Add a {{HostCredentialCallback}} which is basically identical to {{CredentialCallback}}.
This would only be used server-side, to acquire the local host credential. Other
existing uses of {{CredentialCallback}} would then remain unchanged. The advantage to
this approach over #1 is that the client doesn't have to make sure the credential
"type" makes sense (i.e. is "LOCAL" or "CLIENT" as opposed
to "PEER" or "SERVER"). The advantage over #3 is that existing client
and server usages don't have to change.
was (Author: dmlloyd):
Here are some options:
# Add a field to {{CredentialCallback}} to designate local or peer credential, or perhaps
client or server credential. In the Entity mechanism, use {{CredentialCallback}} on the
client and server to acquire the local credential to use, and the general peer trust
callback to verify the peer's public credential. On the client, only local
credentials may be sensibly acquired, but on the server, either local or peer credentials
might be acquired.
# Add a field to {{CredentialCallback}} as above, but stop using
{{VerifyPeerTrustedCallback}} to verify the client, instead using a second (peer)
{{CredentialCallback}} to acquire the user public credential and performing the validation
within the mechanism. The {{VerifyPeerTrustedCallback}} (or its ELY-373 equivalent) would
still be used on the client to verify the server.
# Add a {{LocalCredentialCallback}} which acquires the local credential. Use this
credential on the server to acquire the host credential. Change the client to use this
callback to acquire the user credential on the client. The server would continue to use
{{CredentialCallback}} to acquire the user (peer) credential.
Ambiguous application of CredentialCallback
-------------------------------------------
Key: ELY-374
URL:
https://issues.jboss.org/browse/ELY-374
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Mechanisms, Callbacks, SASL
Reporter: David Lloyd
Priority: Critical
Fix For: 1.1.0.Beta3
We have a problem where there is an ambiguous application of {{CredentialCallback}}.
On the client, this callback is used to acquire the credential to use for outbound
authentication. On the server, it is used in two ways:
* For most authentication, it is used to acquire the credential that is used to verify
the client identity.
* For Entity authentication, it is used to acquire the credential that is used to
identify the server to the client.
The reason Entity can get away with this special behavior is that it uses the
{{VerifyPeerTrustedCallback}} instead of {{CredentialCallbak}} for checking the peer.
Unfortunately, it is not easy for a callback handler to know when {{CredentialCallback}}
is being used for the host identity versus the authenticating user identity. This needs
to be solved ASAP so that we can have server mechanisms that present a host identity as
well as acquiring a credential for user authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)