You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pid <pi...@pidster.com> on 2010/07/07 11:46:16 UTC
Re: SignatureMethodAlgorithm
On 07/07/2010 09:39, Simone Tripodi wrote:
> Hola Pid
>
> On Tue, Jul 6, 2010 at 10:38 PM, Pid <pi...@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
Re: SignatureMethodAlgorithm
Posted by Pid <pi...@pidster.com>.
On 07/07/2010 12:00, Mark Thomas wrote:
> On 07/07/2010 10:46, Pid wrote:
>
> Wrong list me thinks.
Doh. Email address auto-complete FAIL.
p
> Mark
Re: SignatureMethodAlgorithm
Posted by Mark Thomas <ma...@apache.org>.
On 07/07/2010 10:46, Pid wrote:
Wrong list me thinks.
Mark
> On 07/07/2010 09:39, Simone Tripodi wrote:
>> Hola Pid
>>
>> On Tue, Jul 6, 2010 at 10:38 PM, Pid <pi...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org