Hi
I did some work around this issue, see
http://git-wip-us.apache.org/repos/asf/cxf/commit/0987d405
Hopefully it would be easier to override the service; registering a
ClientSecretVerifier instance with it is another option.
I've tried to have the service keeping the control of the overall
validation for the providers not to worry about various boilerplate but
required checks.
I've also updated the service to het CXF MessageContext optionally
injected into data providers - so for example, if the provider is there
to support a client credentials flow then it would be straightforward to
syntesize a client in cases where no container-based authentication is
done and the client is doing Basic auth...
Please experiment with the snapshots and let me know how it goes
Sergey
On 03/11/14 12:39, Sergey Beryozkin wrote:
Hi David
Thanks for posting the question here,
On 03/11/14 11:31, David Payne wrote:
Hi,
This is essentially a duplicate of the following question on Stack
Overflow, but I thought this mailing list might be a better place to ask:
http://stackoverflow.com/questions/26677743/hashed-client-secrets-for-the-client-credentials-oauth-2-flow-in-apache-cxf
My problem is that I want to store my client secrets as hashes, and thus
would (ideally) like to override the
AccessTokenService.getAndValidateClient() method, to perform my own
comparison, rather than just using String.equals() as in the default
functionality.
Am I missing some obvious extension point where I can provide my own
implementation of this, or is there a better way? Perhaps I'm missing
something and shouldn't be thinking of the client secret as a password
(and
therefore hashing it is unnecessary), but I don't think so...
My current proposed alternative is to implement a RequestHandler which
does
all of the validation itself and puts a SecurityContext in the
Message, to
make AccessTokenService trust that the client has already been
authenticated, which is working, but feels like a long way around for
something that I'd expect to be a fairly common requirement.
Any advice would be much appreciated.
As it happens, I've actually analyzed this piece of code recently and
realized it was problematic for the client credential fcases because it
basically enforces the data provider to have cached/pre-registered
Client instances which may be redundant in the client credentials flows
so it won't scale really well...It is possible to syntesize a Client
dynamically even with this code but it would be a bit hacky...
I agree that besides that, the plain equals() comparison is limiting
too, surely Client can have password kept as hashes.
I think the data provider interface could've had something like
getClient(String id, MultivaluedMap<String, String> params) instead so
that the providers could do the right comparisons in such cases;
I will introduce an interface, so that the implementations can be
registered with AccessTokenService, and will also make the relevant code
more extensible...
Will get back to you a bit later
Thanks, Sergey
