tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: SignatureMethodAlgorithm
Date Wed, 07 Jul 2010 09:46:16 GMT
On 07/07/2010 09:39, Simone Tripodi wrote:
> Hola Pid
> 
> On Tue, Jul 6, 2010 at 10:38 PM, Pid <pid@pidster.com> wrote:
>>
>> I'm working on a prototype integrating the signature-api with the config
>> stuff & the spec api.  Couple of things:
>>
>> #1
>>
> 
> no problems/objections, feel free to commit it ;)
> 
>> #2
>>
>> I'm trying to understand whether it would be possible for the
>> SignatureMethodAlgorithm interface to be refactored to just use the Key
>> interface, or (SigningKey, VerifyingKey) directly.
>>
> 
> Unfortunately, nope. That would be easier if we could take in
> consideration only algorithms such PLAINTEXT and HMAC_SHA1, where the
> same key is used to both sign/verify the signature, but with RSA
> things are quite more complicated.
> Using RSA involves users have to use a private key to sign, and a
> public certificate to validate. Sounds reasonable - at least to me -
> that keys have to be typed, since, potentially, trying to verify an
> HMAC signature with an RSA public key is wrong.

I thought as much.  Hmm.

>> I assume it's defined like this so an implementation can require it's
>> own key classes to be used?
>>
>>
>> The problem is that I don't think we will be able to use the
>> ServiceLoader mechanism to discover and use signature implementations.
>>
> 
> I think your idea is still valid, adding just minor modifications,
> something similar that I already did in the past[1]:
> - with the service loader mechanism, you discover all SignatureMethod
> implementations and optionally store them in a Registry;
> - when a client try to generate/verify a signature, by the key it
> could access to the registry and take the relative algorithm.

Yep.  That's the idea.


> Quite clean and easy, thoughts?

In principal, yes, in practice there's some problems that I can't quite
work out.  Whether we use ServiceLoader or an equivalent duplicate, the
problem is as as follows...

Very simply:

 Map<String, SignatureMethod> registry = ...;
 ClassLoader loader = ...;

 ServiceLoader<SignatureMethod> services =
   ServiceLoader.load(SignatureMethod.class, loader);

 for (SignatureMethod sm : services) {
    registry.put(sm.getAlgorithm(), sm);
 }


Without doing massive quantities of reflection - and I don't know if
even that will do it - the SignatureMethod can only be loaded if it is
not enhanced with generic types.

Even if it was possible to store it efficiently, I can't see a way to
then use it.

 String algorithm = oAuthRequest.getAlgorithm();
 SignatureMethod method = registry.get(algorithm);

If method was extracted:

 SignatureMethod<K,V> method = registry.get(algorithm);

We then need *another* mechanism which helps us create the proper,
matching keys K and V so we can create a concrete object.

 K key = createTheKey(oAuthRequest.getSigBase());
   // how do we do this?

 String signature = calculate(key, oAuthRequest);


I'm a bit stumped.  How were you handling this?


p





> Simo
> 
> [1] http://code.google.com/p/asmx-oauth/source/browse/trunk/core/commons/src/main/java/com/asemantics/oauth/core/signers/RequestSignerRegistry.java



Mime
View raw message