oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: Change in authorization server
Date Mon, 25 Mar 2013 15:32:15 GMT
Hi Stein,

good thought!!! Don't feel worried about breaking the amber
backward-compatibility - which already is! :) - because after the
package move they are not compatible anymore.

So, if you need to override an existing class behaviour, just fill an
issue and go ahead - keep up the good work!

All the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sun, Mar 24, 2013 at 2:35 PM, Stein Welberg
<stein@innovation-district.com> wrote:
> A slight adjustment: See inline.
>
> On 24 mrt. 2013, at 14:16, Stein Welberg <stein@innovation-district.com> wrote:
>
>> Hi Guys,
>>
>> Since Simone made a good remark in the another thread (changing/updating groupId/artifactId)
that we are breaking Amber backwards-compatibility, I would like to suggest another change.
I would also like your opinion about the way to implement it.
>>
>> Currently the Oltu Authorization server implementation is not spec compliant regarding
the support for Basic Authentication (see OLTU-5 and OLTU-16). According to the spec section
2.1.3 [0] the authorization server must support basic authentication. I am currently trying
to figure out a way to support both unauthenticated requests and authenticated requests (either
using basic authentication or not). The unauthenticated requests will not have the client_secret
parameter since they possibly don't have a client_secret.
>>
>> The current setup of the validators does not allow us to dynamically make a param
(e.g. the client_secret) required or optional based on some parameter. The validators are
added in the OAuthTokenRequest so this is the place to create the distinction between an unauthenticated
request an an authenticated request. Without doing a real big refactoring of the validators
we have two options to support both authenticated and unauthenticated requests:
>>
>> 1. One way to do this is by creating another OAuthTokenRequest class that accepts
only authenticated requests (the OAuthAuthenticatedTokenRequest class). The plain OAuthTokenRequest
class then only handles unauthenticated requests.
>
> Instead of creating a new class that handles authenticated token requests, I would suggest
to create a new class with the name OAuthnUnauthenticatedTokenRequest and change the behavior
of the OAuthTokenRequest class to only support authenticated requests. This also with regards
to encourage sensible (secure) defaults.
>
> Regards,
> Stein
>
>>
>> 2. The second option is to use a boolean in the constructor of the OAuthTokenRequest
class to indicate whether we want Oltu to treat the request as an authenticated request or
not. I would suggest that we enforce authentication by default and that adding the boolean
to the constructor would make it possible to also support unauthenticated requests (secure
defaults).
>>
>> My preference goes to the first approach where we create a separate class purely
for authenticated requests since it creates more readable code. (code with booleans in a method
tend to get quite unreadable quickly!)
>>
>> I would like to have your opinions since this is quite a change in the API for the
developers that are going to use Oltu to create an authorization server!
>>
>> Thanks.
>>
>> Regards,
>> Stein
>>
>> [0] http://tools.ietf.org/html/rfc6749#section-2.3.1
>

Mime
View raw message