oltu-dev 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 11:05:10 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'll try sending this to the right list this time, I sent to Tomcat
before. Doh.)

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?


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

View raw message