Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.214.49 as permitted sender)
Message-ID: <5101811E.5040106@gmail.com>
Date: Thu, 24 Jan 2013 18:44:46 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: Implementing the OAuth 2.0 Authorization Code Grant Flow
References: 
 <CANgkmLA_3afcRGeqZ8oYEUfQE25+kJSoTpsGS64cKTTPzmj=vw@mail.gmail.com>
 <50FE7690.7060201@gmail.com>
 <CANgkmLCgeJ1CpFcWU0fvU8eDm_63ZuxoRv=UngbbUEztx6MRow@mail.gmail.com>
 <50FEC7F6.8030302@gmail.com>
 <CANgkmLALTd7dP-XHRF3e21qDq03eyH_w7ORQnr8TWMVLsrS3bg@mail.gmail.com>
 <50FF009E.10400@gmail.com> <51013300.7050804@gmail.com>
 <510156A5.5070101@gmail.com>
 <CANgkmLBY5RMbTs1CkwXVbovn0b5g4F+vSshbS2W7b_+Wn8SKJg@mail.gmail.com>
In-Reply-To: 
 <CANgkmLBY5RMbTs1CkwXVbovn0b5g4F+vSshbS2W7b_+Wn8SKJg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 24/01/13 18:16, Craig McClanahan wrote:
> Validating at the start makes sense to me.

This can be optionally done if needed for the integration purposes, I 
guess given that Saleforce does it this way it is probably important in 
your case to get the same order (validate then authenticate) 
supported... Not sure I can do it for 2.7.3 but it is realistic

>
> The key difference right now is that, when I start the Authorization Code
> Grant flow (Section 4.1) with no credentials, I want CXF to redirect to the
> login UI instead of returning 401.
>
This is actually easy to do right now :-). CXF AS, being the ultimate 
destination of the request enforces that the user is authenticated, AS 
itself is not dealing with the end user authentication enforcement.
You have a couple of options:
1. register NotAuthorizedExceptionMapper with AS endpoint, and convert 
the exception to Respone with either some empty class or enum entity for 
the runtime to be able to check the registered message writers, next 
register RequestDispatcherProvider and link this class or enum to some 
JSP page which will offer an authentication form:

http://cxf.apache.org/docs/jax-rs-redirection.html#JAX-RSRedirection-WithRequestDispatcherProvider

this will work OK if the auth page is generated, it is a server side 
redirect.


2. If the client needs to be redirected, simply convert this exception 
to Response redirecting to a given page


1 & 2 above can also be done from CXF RequestHandler filter or 2.0 
ContainerRequestFilter if it can detect that the message has no 
authentication info available (the former - via 
message.get(SecurityContext.class), latter - via injected JAX-RS 
SecurityContext)

Can you give the above a try please ?
Cheers, Sergey


> Craig
>
> On Thu, Jan 24, 2013 at 7:43 AM, Sergey Beryozkin<sberyozkin@gmail.com>wrote:
>
>> The only thing which is different from the way CXF manages the start of
>> the authorization request is that Salesforce will validate the redirect
>> parameters (client id, redirect uri, request type) before actually
>> presenting that initial authentication screen, while CXF will do it at the
>> end of the authorization request.
>>
>> Is this difference in the way the authorization request is managed
>> important for your purpose of interposing Salesforce service ?
>>
>> I think we can relatively easy configure AS to validate at the start of
>> the process too, let me know please
>>
>> Sergey
>>
>>
>> On 24/01/13 13:11, Sergey Beryozkin wrote:
>>
>>> Hi
>>> On 22/01/13 21:11, Sergey Beryozkin wrote:
>>>
>>>> On 22/01/13 18:58, Craig McClanahan wrote:
>>>>
>>>>> On Tue, Jan 22, 2013 at 9:10 AM, Sergey
>>>>> Beryozkin<sberyozkin@gmail.com**>wrote:
>>>>>
>>>>>
>>>>>>   Yes, the only limitation in CXF at the moment is that it does it
>>>>>>>> with a
>>>>>>>>
>>>>>>> sequence of forms, whereas you'd like to have a single form asking
>>>>>> for both
>>>>>> authentication credentials and the authorization approval/denial in the
>>>>>> same/single view - obviously a presentation builder would need to know
>>>>>> somehow of the authentication scheme supported by AS.
>>>>>>
>>>>>> I need to think a bit more about it.
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>> At the end of the day, what I'm trying to do is set up a "mock"
>>>>>> version of
>>>>>>
>>>>> Salesforce, including a couple of dummy services, for the purposes of
>>>>> exercising our OAuth client code against something easy to set up in
>>>>> a CI
>>>>> environment. I was delighted to see that I might not have to implement
>>>>> all
>>>>> the server side logic, but need to figure out a way around this one.
>>>>>
>>>>
>>>> I'll experiment with the way Salesforce does it; I might just add a
>>>> property to AS that will let users configure it to accept
>>>> unauthenticated requests in which case it will set a flag for the
>>>> presentation layer to know it needs to offer an authentication option
>>>> alongside the authorization data - the way things are done now, it is
>>>> completely up to the security layer how to collect the authentication
>>>> credentials, but I guess when it is well known that say Basic Auth is
>>>> used then this composite presentation option is also possible, I'll look
>>>> into it
>>>>
>>>>   I haven't proceeded to actually creating a Salesforce account, still
>>> reading a bit, in here:
>>>
>>> http://wiki.developerforce.**com/page/Getting_Started_with_**
>>> the_Force.com_REST_API<http://wiki.developerforce.com/page/Getting_Started_with_the_Force.com_REST_API>
>>>
>>>
>>> it shows two separate screens, first the user is prompted to
>>> authenticate (if not authenticated), next - approve.
>>>
>>> This style will definitely work with CXF, but I guess those screens may
>>> be outdated
>>>
>>> Actually - just spent some time creating a SalesForce developer account,
>>> a basic test application and then updated Talend demo to redirect to it
>>> to authorize just to see the screens and I do see only the
>>> authentication dialog on the first screen.
>>>
>>> Can we talk more about the actual requirements on your end ?
>>>
>>>
>>>
>>> Thanks, Sergey
>>>
>>>
>>>>> BTW, do you know of any open sourced sample apps that use the OAuth 2
>>>>> stuff? It's always interesting to learn from how other people have
>>>>> used it.
>>>>>
>>>>>   Apache Oltu (formerly Amber) may be of help too, there are few
>>>> differences in the way OAuth2 is implemented there, but check them out
>>>> please too - there could be some relevant demos
>>>>
>>>> Cheers, Sergey
>>>>
>>>>   Craig
>>>>>
>>>>>
>