cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Payne <david.pa...@propagatorgroup.com>
Subject Re: AccessTokenService Client Secret Validation
Date Wed, 05 Nov 2014 13:30:16 GMT
This is great, thanks very much Sergey. I'll take a look when I am able,
but it's unlikely to be this week.

On 5 November 2014 12:10, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

> I added a ClientSecretHashVerifier implementation which calculates an
> SHA-256 hash by default
>
> Sergey
>
> On 04/11/14 13:41, Sergey Beryozkin wrote:
>
>> 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
>>>
>>>
>>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message