oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: svn commit: r962443 - /incubator/amber/trunk/spec-api/src/main/java/org/apache/amber/signature/SignatureMethod.java
Date Fri, 09 Jul 2010 10:27:54 GMT
Ok I understood your point of view, thanks for showing the use case.
I see things different, because of the past experiences, this is what
we successfully did in the past:

On the Server side, the scenario is that when receiving the OAuth
request, extracting oauth_consumer_key AND oauth_signature_method we
retrieve (from a proper Storage that's currently missing) the relative
key.
We can't assume things too generic because for the RSA algorithm that
works with certificates, and things are totally different.

String consumerKey = extractFrom(request);
String methodName = extractFrom(request);

 SignatureMethod<SignatureKey, VerifyingKey> method =
signatureMethodsRegistry.get(methodName);
 VerifyingKey key = fromStorage(consumerKey, methodName);
 method.verify(key, request);

If you play a little with providers (try oauthplayground) you can see
how it is a common practice associating ONE key/certificates for each
method for each consumer, clients shall not be able to sign request
with more than one key for the same method, otherwise Providers should
guess with which of n keys for the same method the signature has been
signed.
At the same time, it doesn't mean that Consumers have just one key,
they can have the RSA certificate, a secret for HMAC, a secret for
PLAINTEXT... but just one for method.

What someone else experienced?
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Jul 9, 2010 at 12:02 PM, Pid <pid@pidster.com> wrote:
> On 09/07/2010 10:44, Simone Tripodi wrote:
>> sure! with just a very simple key proto we should be able to fill the
>> lack caused by generics. for RSA, as already know, things are a little
>> more complicated, where SigningKey and VerifyingKey implementations
>> are totally different.
>> just thinking about how to reuse the same key for new custom
>> algorithms implementations.
>>
>> public final class BasicKey implements SigningKey, VerifyingKey {
>
>
> What I'm getting at is this:
>
>  String methodName = extractFrom(request);
>  SignatureMethod method = registry.get(methodName);
>  // create keys
>
>  method.verify(etc, etc)
>
> It's very difficult to do the above when you don't know the key types,
> if SignatureMethod is parameterized.
>
>  SignatureMethod<K,V> method = registry.get(methodName);
>  // how to select/create the key K?
>
>
> I'm trying to work on the discovery of SignatureMethods and some
> mechanism for selecting them.  The current design only works if I write
> code which differentiates between each type, which negates the point of
> using generics.
>
>
> p
>
>
>
>
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Fri, Jul 9, 2010 at 11:21 AM, Pid <pid@pidster.com> wrote:
>>> On 09/07/2010 10:18, Simone Tripodi wrote:
>>>> Hi Pid,
>>>> thanks for understanding, in a while I'll be able to show you the
>>>> alternative we're looking for to sign/verify signatures simply with
>>>> String, I hope you'll enjoy the solution :P
>>>
>>> I'd prefer to have a discussion about it, even if it's a short one,
>>> before code is committed, if possible.
>>>
>>>
>>> p
>>>
>>>
>>>> On Fri, Jul 9, 2010 at 11:08 AM, Pid <pid@pidster.com> wrote:
>>>>> On 09/07/2010 09:43, Simone Tripodi wrote:
>>>>>> Hi Pid,
>>>>>> in that way you're able to verify an HMAC signed signature with an
RSA
>>>>>> verifying key, that's wrong by nature.
>>>>>
>>>>> I understand that problem, I'm trying to find a way to avoid generics
>>>>> for this package.  Otherwise we'll have to hard code each sig method
in
>>>>> the implementation.
>>>>>
>>>>>>> +
>>>>>>> +    /**
>>>>>>> +     * @param value
>>>>>>> +     * @return key
>>>>>>> +     */
>>>>>>> +    SigningKey createSigningKey(String... value);
>>>>>>> +
>>>>>>> +    /**
>>>>>>> +     * @param value
>>>>>>> +     * @return key
>>>>>>> +     */
>>>>>>> +    VerifyingKey createVerifyingKey(String... value);
>>>>>>>
>>>>>>
>>>>>> uhm I really don't think keys have to be generated by an algorithm
>>>>>> that the task to sign/verify a signature, Keys can be defined
>>>>>> independently by the algorithm implementation.
>>>>>
>>>>> Please see my previous email thread on this topic.
>>>>>
>>>>> Currently it will not be possible to look up a SignatureMethod instance
>>>>> using a String identifier as a key.  We need a solution to the problem,
>>>>> either by working around it or by coming up with an alternative.
>>>>>
>>>>> The current interface design simply will not work, as far as I can tell
>>>>> - please advise if you believe otherwise.
>>>>>
>>>>>
>>>>>> BTW I was integrating the Signature api to the implementation to
the
>>>>>> already existing codebase and that modification broke my work, can
you
>>>>>> please advice me before you want to modify it, to avoid we both have
>>>>>> problems? Can you please rollback that class? Thanks in advance,
very
>>>>>> appreciated :)
>>>>>
>>>>> Apologies, done.
>>>>>
>>>>>
>>>>> p
>>>>>
>>>>>> Simo
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>

Mime
View raw message