Mailing-List: contact dev-help@oltu.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@oltu.apache.org
Received-SPF: pass (nike.apache.org: domain of simone.tripodi@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Sender: simone.tripodi@gmail.com
In-Reply-To: <78C1A0D1-01BD-4306-A32C-59F1E0F85B4E@innovation-district.com>
References: <B6BAA8D7-6E23-4385-9635-28DD23A66261@innovation-district.com>
	<78C1A0D1-01BD-4306-A32C-59F1E0F85B4E@innovation-district.com>
Date: Mon, 25 Mar 2013 16:32:15 +0100
Message-ID: 
 <CAAqLGLMyLVGc0RTPC3FDKsASagFOhsVVViY=7Z9FoEXeHP7SXA@mail.gmail.com>
Subject: Re: Change in authorization server
From: Simone Tripodi <simonetripodi@apache.org>
To: dev@oltu.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 compl=
iant 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 su=
pport basic authentication. I am currently trying to figure out a way to su=
pport both unauthenticated requests and authenticated requests (either usin=
g 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 mak=
e a param (e.g. the client_secret) required or optional based on some param=
eter. The validators are added in the OAuthTokenRequest so this is the plac=
e to create the distinction between an unauthenticated request an an authen=
ticated 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 tha=
t accepts only authenticated requests (the OAuthAuthenticatedTokenRequest c=
lass). 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 OAuthnUnauthenticated=
TokenRequest and change the behavior of the OAuthTokenRequest class to only=
 support authenticated requests. This also with regards to encourage sensib=
le (secure) defaults.
>
> Regards,
> Stein
>
>>
>> 2. The second option is to use a boolean in the constructor of the OAuth=
TokenRequest class to indicate whether we want Oltu to treat the request as=
 an authenticated request or not. I would suggest that we enforce authentic=
ation 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 clas=
s purely for authenticated requests since it creates more readable code. (c=
ode 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 A=
PI 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
>