oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.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 11:38:47 GMT
On 09/07/2010 11:27, Simone Tripodi wrote:
> 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);

Yes, I got that far, but can we not achieve the same without generics?

Also, doesn't the fromStorage() method need to hard code the class
instantiation of the implementation for each key class?

How does it know which class to use?  We only know about the
SignatureMethod at this point - we don't know about the key implementations.

This is why I was thinking about adding a method to the SignatureMethod
interface which provides the key implementation for the method in use.


> 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.

I completely agree with that, no issue there from me.
The key selection logic would prevent the wrong key being used with the
wrong type anyway, no?


p

> 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