You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Pid <pi...@pidster.com> on 2010/07/06 22:38:31 UTC
SignatureMethodAlgorithm
I'm working on a prototype integrating the signature-api with the config
stuff & the spec api. Couple of things:
#1
I'd like to propose a relatively minor cosmetic change:
s/SignatureMethodAlgorithm/SignatureMethod/
and,
s/getAlgorithmMethod/getAlgorithm/
... slightly less of a mouthful this way.
I'll commit it tomorrow unless anyone objects.
#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.
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.
In fact it will be hard to use any form of interface which uses generics
in this way.
I had anticipated being able to perform a lookup, like so:
SignatureMethodAlgorithm getSignatureMethod(String algorithm);
Thoughts/comments?
p
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
Re: SignatureMethodAlgorithm
Posted by Pid <pi...@pidster.com>.
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 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'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?
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 Simone Tripodi <si...@gmail.com>.
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 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.
Quite clean and easy, thoughts?
Simo
[1] http://code.google.com/p/asmx-oauth/source/browse/trunk/core/commons/src/main/java/com/asemantics/oauth/core/signers/RequestSignerRegistry.java