You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Antonio Sanso <as...@adobe.com> on 2012/02/06 11:26:46 UTC
Resource Server refactor
Hi *,
just try to gain some opinion about AMBER-48 [0].
I hope you all agree a refactor is needed.
Said that, I was wondering what you think on how to proceed.
In my mind I can see two basic options:
1. Have the current resource resolver module as base. And have different modules (that leverage resource resolver) implementing the specific token type specification (e.g Bearer - resource resolver bearer, MAC ...)
2. Do the refactor keeping everything in the same module (existing resource resolver)
WDYT?
Regards
Antonio
[0] https://issues.apache.org/jira/browse/AMBER-48
Re: Resource Server refactor
Posted by Simone Tripodi <si...@apache.org>.
Hola ;)
>>
>> that is something Pid and I tried to work on in the spec-api package,
>> see https://svn.apache.org/repos/asf/incubator/amber/trunk/spec-api/src/main/java/org/apache/amber/server
>
> Cooool!! Let's be sure this is not going to be lost with the SVN tidy up!!!
>
of course, even if a little outdated, the older code still contains
few good ideas - Pid and I passed weeks arguing without committing, to
find a common agreement on APIs :D
Fortunately, old times have passed :)
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: Resource Server refactor
Posted by Antonio Sanso <as...@adobe.com>.
On Feb 7, 2012, at 10:53 AM, Simone Tripodi wrote:
> Hi + (hope at least one will read my message :D)
lol
>
> On Tue, Feb 7, 2012 at 10:03 AM, Tommaso Teofili
> <to...@gmail.com> wrote:
>> 2012/2/6 Raymond Feng <en...@gmail.com>
>>
>>> Hi,
>>>
>>> Adding a layer that supports the extensions of oAuth 2.0 (the spec already
>>> mentions the extensions) is definitely desired.
>>>
>>
>> +1
>>
>
> +1 as well
>
>>
>>>
>>> Based on my usage/experience with Amber, we should probably go beyond just
>>> the resource server that allows multiple types of token. I would like to
>>> see some SPIs that allow the adopters of oAuth 2.0 to plug in their own
>>> infrastructures. To name a few,
>>>
>>> * TokenGenerator (generating the tokens based on the token types)
>>> * TokenManager (managing the tokens)
>>> * Authenticator (authenticates the client and resource owners)
>>>
>>
>> definitely +1 here too!
>>
>
> that is something Pid and I tried to work on in the spec-api package,
> see https://svn.apache.org/repos/asf/incubator/amber/trunk/spec-api/src/main/java/org/apache/amber/server
Cooool!! Let's be sure this is not going to be lost with the SVN tidy up!!!
>
>>
>>>
>>> We also need to have a way to wire the service providers into the oAuth
>>> 2.0 base. Something like JAX-RS ContextResolver, Google Guice or the JDK
>>> META-INF/services/ pattern can be used to connect the pieces together.
>>>
>>
>> I agree and I'd be keen to use base JDK META-INF/services method to avoid
>> introducing other dependencies.
>>
>
> +1 for keeping Amber with as less dependencies as possible, but
> keeping an eye with external providers (see the BeanValidation
> specification) so my *personal* vision is implementing a set of
> interfaces for providers AND some _separated_ implementations (like
> the one mentioned) but no once defined by default (or maybe the JKD
> SPI that comes "for free")
At the moment we have a filter implementation as a way to plug in....
https://svn.apache.org/repos/asf/incubator/amber/trunk/oauth-2.0/oauth2-rs-filter/
Regards
Antonio
>
> all the best, have a nice day!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
Re: Resource Server refactor
Posted by Simone Tripodi <si...@apache.org>.
Hi + (hope at least one will read my message :D)
On Tue, Feb 7, 2012 at 10:03 AM, Tommaso Teofili
<to...@gmail.com> wrote:
> 2012/2/6 Raymond Feng <en...@gmail.com>
>
>> Hi,
>>
>> Adding a layer that supports the extensions of oAuth 2.0 (the spec already
>> mentions the extensions) is definitely desired.
>>
>
> +1
>
+1 as well
>
>>
>> Based on my usage/experience with Amber, we should probably go beyond just
>> the resource server that allows multiple types of token. I would like to
>> see some SPIs that allow the adopters of oAuth 2.0 to plug in their own
>> infrastructures. To name a few,
>>
>> * TokenGenerator (generating the tokens based on the token types)
>> * TokenManager (managing the tokens)
>> * Authenticator (authenticates the client and resource owners)
>>
>
> definitely +1 here too!
>
that is something Pid and I tried to work on in the spec-api package,
see https://svn.apache.org/repos/asf/incubator/amber/trunk/spec-api/src/main/java/org/apache/amber/server
>
>>
>> We also need to have a way to wire the service providers into the oAuth
>> 2.0 base. Something like JAX-RS ContextResolver, Google Guice or the JDK
>> META-INF/services/ pattern can be used to connect the pieces together.
>>
>
> I agree and I'd be keen to use base JDK META-INF/services method to avoid
> introducing other dependencies.
>
+1 for keeping Amber with as less dependencies as possible, but
keeping an eye with external providers (see the BeanValidation
specification) so my *personal* vision is implementing a set of
interfaces for providers AND some _separated_ implementations (like
the one mentioned) but no once defined by default (or maybe the JKD
SPI that comes "for free")
all the best, have a nice day!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: Resource Server refactor
Posted by Tommaso Teofili <to...@gmail.com>.
2012/2/6 Raymond Feng <en...@gmail.com>
> Hi,
>
> Adding a layer that supports the extensions of oAuth 2.0 (the spec already
> mentions the extensions) is definitely desired.
>
+1
>
> Based on my usage/experience with Amber, we should probably go beyond just
> the resource server that allows multiple types of token. I would like to
> see some SPIs that allow the adopters of oAuth 2.0 to plug in their own
> infrastructures. To name a few,
>
> * TokenGenerator (generating the tokens based on the token types)
> * TokenManager (managing the tokens)
> * Authenticator (authenticates the client and resource owners)
>
definitely +1 here too!
>
> We also need to have a way to wire the service providers into the oAuth
> 2.0 base. Something like JAX-RS ContextResolver, Google Guice or the JDK
> META-INF/services/ pattern can be used to connect the pieces together.
>
I agree and I'd be keen to use base JDK META-INF/services method to avoid
introducing other dependencies.
My 2 cents,
Tommaso
>
>
> Thanks,
> Raymond
>
> On Feb 6, 2012, at 2:26 AM, Antonio Sanso wrote:
>
> > Hi *,
> >
> > just try to gain some opinion about AMBER-48 [0].
> > I hope you all agree a refactor is needed.
> > Said that, I was wondering what you think on how to proceed.
> > In my mind I can see two basic options:
> >
> > 1. Have the current resource resolver module as base. And have different
> modules (that leverage resource resolver) implementing the specific token
> type specification (e.g Bearer - resource resolver bearer, MAC ...)
> > 2. Do the refactor keeping everything in the same module (existing
> resource resolver)
> >
> > WDYT?
> >
> > Regards
> >
> > Antonio
> >
> > [0] https://issues.apache.org/jira/browse/AMBER-48
>
>
Re: Resource Server refactor
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Adding a layer that supports the extensions of oAuth 2.0 (the spec already mentions the extensions) is definitely desired.
Based on my usage/experience with Amber, we should probably go beyond just the resource server that allows multiple types of token. I would like to see some SPIs that allow the adopters of oAuth 2.0 to plug in their own infrastructures. To name a few,
* TokenGenerator (generating the tokens based on the token types)
* TokenManager (managing the tokens)
* Authenticator (authenticates the client and resource owners)
We also need to have a way to wire the service providers into the oAuth 2.0 base. Something like JAX-RS ContextResolver, Google Guice or the JDK META-INF/services/ pattern can be used to connect the pieces together.
Thanks,
Raymond
On Feb 6, 2012, at 2:26 AM, Antonio Sanso wrote:
> Hi *,
>
> just try to gain some opinion about AMBER-48 [0].
> I hope you all agree a refactor is needed.
> Said that, I was wondering what you think on how to proceed.
> In my mind I can see two basic options:
>
> 1. Have the current resource resolver module as base. And have different modules (that leverage resource resolver) implementing the specific token type specification (e.g Bearer - resource resolver bearer, MAC ...)
> 2. Do the refactor keeping everything in the same module (existing resource resolver)
>
> WDYT?
>
> Regards
>
> Antonio
>
> [0] https://issues.apache.org/jira/browse/AMBER-48