oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <pids...@apache.org>
Subject Re: APIs
Date Tue, 15 Jun 2010 17:54:35 GMT
On 15/06/2010 16:14, Simone Tripodi wrote:
> Hi Simo,
> absolutely right, let's find a better way to describe how I started
> designing the signature APIs...
> 
> First of all: use cases show us that there are symmetric algorithms
> (PLAINTEXT, HMAC_SHA) and asymmetric algorithms (RSA_SHA1), so the
> design should be able to be adaptable for both cases. I thought that a
> symmetric algorithm is a special case of an asymmetric algorithm, so
> let's consider having a SigningKey and a VerifyingKey interfaces, in
> the case of a symmetric algorithm, the key implementation have to
> implement both interfaces.
> 
> So, let's define the SignatureMethodAlgorithm - I hope the name is
> semful!!! That's the interface definition
> 
> public interface SignatureMethodAlgorithm<S extends SigningKey, V
> extends VerifyingKey>
> 
> where defined the the method to calculate the signature (throws
> SignatureException if any error occurs):
> 
>     String calculate(S signingKey,
>             String secretCredential,
>             Service service,
>             RequestMessage message,
>             Parameter... parameters) throws SignatureException;
> 
> and the one to verify the signature:
> 
> boolean verify(String signature,
>             V verifyingKey,
>             String secretCredential,
>             Service service,
>             RequestMessage message,
>             Parameter... parameters) throws SignatureException;
> 
> An abstract implementation, AbstractSignatureMethodAlgorithm, contains
> common signature calculation stuff, like the base string creation.
> Any SignatureMethodAlgorithm implementation is annotated by a
> @SignatureMethod annotation to mark the oauth algorithm identifier,
> ie:
> 
> @SignatureMethod("HMAC-SHA1")
> public final class HmacSha1MethodAlgorithm extends
> AbstractMethodAlgorithm<HmacSha1Key, HmacSha1Key> {
> ...
> }
> 
> Let's now make clear what hell Service, RequestMessage and Parameter are :)
> 
> 
> Service is the pair (URL, HttpMethod) that describes the service has
> to be invoked. HttpMethod is an enumeration of all admitted http
> method:
>     HEAD,
>     POST,
>     PUT,
>     GET,
>     DELETE,
>     OPTIONS,
>     TRACE,
>     CONNECT
> 
> 
> RequestMessage is a POJO that contains the OAuth parameters like
> version, nonce, timestamp, ... it is extended by the
> TokenRequestMessage that differs from the previous one because
> contains the token field.
> Every RequestMessage field is annotated by @OAuthParameter annotation,
> to mark if the field:
> - is optional (false by default)
> - has to be included in the parameter list to calculate the signature
> (true by default)
> - moreover contains the oauth parameter name
> 
> a sample can be found on the signature field:
> 
> @OAuthParameter(
>             name = "oauth_signature",
>             includeInSignature = false
>     )
>     private String signature;
> 
> That's all in therms of design, there are few little tricks on the
> implementation side (java introspection rocks) but IMHO is small and
> intuitive.
>
> What do you think about it? Thoughts? Any feedback is more than welcome!!!!

I hope you'll forgive me for saying so, but I think it's quite
complicated.  Annotations are nice, but seem like overkill for this
use-case.

If the POJO contains all of the necessary items as named fields, why not
just concatenate and encode them in the correct order?


p


(Sorry Simo!)






> All the best, have a nice reading :P
> Simo
> 
> http://people.apache.org/~simonetripodi/
> 
> 
> 
> On Tue, Jun 15, 2010 at 4:17 PM, Simone Gianni <simoneg@apache.org> wrote:
>> Hi Simo,
>> obviously current SVN *is* the starting point.
>>
>> Let's see how to continue on that line, if there are other proposals, if
>> some of our other existing code bases approach in a different way, or if
>> someone foresees some other kind of problems in integrating the current API
>> with their app.
>>
>> Simone
>>
>> 2010/6/15 Simone Tripodi <simone.tripodi@gmail.com>
>>
>>> Hi Simo,
>>> currently in the current svn Amber repo there is the signature (with
>>> implementation) and part of consumer APIs I wrote time ago for the
>>> Lab.
>>> They are still valid IMHO and part of my proposal, parts of code could
>>> be extracted from there.
>>>
>>> Feel free to ask questions if some parts are not clear.
>>> All the best,
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>>>
>>>
>>>
>>> On Tue, Jun 15, 2010 at 2:21 PM, Simone Gianni <simoneg@apache.org> wrote:
>>>> Hi all,
>>>> so, one part of our roadmap are APIs.
>>>>
>>>> Each of us has his own idea of how an API should be, in general, and many
>>> of
>>>> us already have an idea (or even code) on how an OAuth API should be :)
>>>>
>>>> There is no "absolute way" to determine if an API is better or worse than
>>>> another. It mostly depends on use cases.
>>>>
>>>> Amber will (as many other systems) interact with :
>>>> - external applications/frameworks, using Amber to integrate oauth
>>>> - internal extensions, providing for example different token storages or
>>>> interation different backends
>>>> - modules of Amber itself
>>>>
>>>> I think it would be better to focus on the first API now : which use
>>> cases
>>>> do we plan? How do you imagine the code of a web framework using Amber
>>> look
>>>> like?
>>>>
>>>> If there are very different cases there is space for more than one API,
>>> for
>>>> example a low level one and high level Fa├žade. Since our goal is to unify
>>>> different (often existing) pieces and ease the path of adoption on
>>> projects
>>>> that were planning to integrate OAuth, we'll need a bit of flexibility.
>>>>
>>>> Cast your code sample ideas :) People in projects that already use their
>>> own
>>>> implementation of OAuth can easily post real code.
>>>>
>>>> Simone
>>>>
>>>
>>



Mime
View raw message