On 20/11/13 01:34, Jason Wang wrote:
Thanks for the clarification. I can see scope and permissions are all for
"client" rather than "resource owners".

But if the client acts as a resource owner then RO is effectively a client, right ?

In terms of the 2 phase login, I achieved it by providing my own token and
my own oauthRequestFilter.

Can you think of some extension point in the shipped filter ?


I am trying to upgrade cxf version of an old project from 2.6.2 to the
latest 2.7.7 but I got a few compiling errors saying
ClientWebApplicationException and ServerWebApplicationException do not
exist -- my code directly references them.



I found that I can use 2.6.9 but not 2.7.0.

So just wondering from 2.7.0, what has been changed??

They existed in
cxf-rt-frontend-jaxrs-2.6.9.jar, package org.apache.cxf.jaxrs.client.

They were removed, see my other response
Sergey
Many thanks,

Jason






On Wed, Nov 20, 2013 at 11:21 AM, Sergey Beryozkin <[email protected]>wrote:

On 19/11/13 21:48, wang lei wrote:

Sergey, the enhancement requirement is raised here
https://issues.apache.org/jira/browse/CXF-5402. I can see you already
resolved it.
This is the level of support you will not get from any premier service
with
any commercial product. Really appreciate this.

Thanks, nothing special really on our end, the issues have proved to be
very easy to solve, I'm postponing on more complex ones, and we are just
going a bit hyper-active as Dan is working on the releases right now.


Yes you are right, I am using alot of my own GrantHandler, my own
OauthUtils to make it work. Thats the painful part I talked about.

Another question would be: (Let me know if you want me to start another
thread) I need a two phase login process.
The first one is about password and username validation, if passes, the
Resource owner flow can grant the access token.

Then I would like this token to be used to do the second phase login, for
example, providing answer to a some questions.
Once passed, then the token can be used to call any other services.

Is there a way to achieve this with the current token structure? Is
"scope"
designed for this purpose?


Returned 'scope' is an optional hint to the client what exactly
Authorization Service (AS) allocated to a given access token, for example,
if the client requested a read and write access, and AS returned 'read'
only then the client can adjust its function and not to offer the users
write-related options, etc.

Re a 2-phase login, is it better be done before issuing a token ? Or may
be you can create a custom handler which will issue yet another token after
the 2nd phase passes, not really sure though, as I don;t see how your whole
application is supposed to function (as far as the interaction with a user
is concerned)

Cheers, SErgey


  Many thanks,



On Wed, Nov 20, 2013 at 5:29 AM, Sergey Beryozkin <[email protected]
wrote:

  I've reviewed the code and I'm certain the behavior is correct with the
respect to the owner flow client_id expectations.

Basically, the spec says that if the client_id is not present then the
runtime needs to recognize the authenticated clients which used some
other
mechanism, for example, the client may have used the client certificates,
Kerberos or something else. The CXF does not know in such cases how to
map
an authenticated client  to its Client representation and as such the
authenticated client has to be mapped to a client id, example, from the
filter, etc.

AccessTokenService will only recognize Basic Authentication if no
client_id is available.

Ad if it is is a pubic client then of course it can not authenticate and
as such a client_id must be available though the service needs to be
configured to support public clients

I'm still curious though what you mean with

"One is that no way to report back error from a customized loginHandler"

You can simply throw "new NotAuthorizedException" or new
WebApplicationException(404) from it, or is it something else ?

Thanks, Sergey


On 19/11/13 11:58, Sergey Beryozkin wrote:

  On 19/11/13 11:55, Sergey Beryozkin wrote:

  On 19/11/13 11:48, wang lei wrote:

  Sergey, I had a number of issues when trying to implement the resource
owner flow.
Its a very painful process. After 8 hours of hair pulling, it worked
in the
end.


I won't try to convince you otherwise, though I have my reservations,
good to know you made it work in the end


  I will raise a few enhancement/bugs in the jira later.

One of them: https://issues.apache.org/jira/browse/CXF-5396


yes, thanks, got it fixed, the typo, note it is very easy to do a
resource owner flow even without the client utils, simply use WebClient
directly and set few form parameters


And two more enhancement/bugs are yet to raise. One is that no way to
report back error from a customized loginHandler.

  OK,

  The other one is that AccessTokenService must require a client ID,
however
the Resource owner flow may not need the client id.

   Hmm... Lets see



right, we are talking about public clients then ? You will need to
configure AccessTokenservice to support public clients, that should help

Sergey


  Thanks. Sergey

   Many thanks,







On Tue, Nov 19, 2013 at 11:18 PM, Sergey Beryozkin
<[email protected]>wrote:

   Hi


On 18/11/13 23:46, wang lei wrote:

   Sergy, I needed to move the segment to the last part otherwise the

entire
query will be dropped somehow.

After that change, it seems the implicit flow its working. I just
need to
work on the client part, like create a sample Andriod app with the
registered URL scheme to extract the segment.

For the authorize code flow  vs implicit flow. According to the
recommendation from the spec, we should not be using client secret
when
dealing with native apps. That way, the code flow works not much
different
to the implicit flow. Although I do find a couple of attaches that
can be
done for the URL scheme registered.

    Authorization code flow can support public clients (such as
mobile
apps)

  and in such cases it can be configured to deliver the code back to
the user
or some back channel, in the former case it can be expected the the
authenticated user will securely enter the code into the device for
it to
exchange the code for a new access token, no client secrets are
involved.

I'm not trying to actively discourage you from using the implicit
flow, I
guess that if done carefully and especially in the more closed
environments
it can be made secure, but I'm repeating what I've learned myself so
far
about the authorization code flow.


    Now I would like to try the Resource Owner flow, as there is no
redirect,

  would be better user experience.  Will let you know how I go.

    Please do

  Cheers, Sergey

    Many thanks,



On Tue, Nov 19, 2013 at 11:01 AM, Sergey Beryozkin
<[email protected]

  wrote:


    Hi


On 18/11/13 17:34, wang lei wrote:

    Sergey,


Isn't implicit flow designed to be used by clients such as mobile
apps?
can
you please explain a little bit more on using authorization code
flow
for
public client? Any reason, advantages?

     I've read so far the experts recommending to use the
authorization
code

   flow whenever possible. The implicit flow does not get a very
good

'press'
though, it definitely requires much more care. CXF does some extra
work
based on the comments I've seen (example it can report back the
client id
for the browser client to validate it is the same id), etc. Please
check
OAuth2 archives, blogs for more steps which may have to be done to
get
the
implicit flow as secure as possible


     I have raised a bug at here regarding the implicitGrantService.

   https://issues.apache.org/jira/browse/CXF-5395


Unless that bug is fixed, I think there is no way to get implicit
flow
to
work.

     I think it is not exactly the case. The encoding issue there
is
real
but

   the easy workaround exists, the service also correctly reports
the

parameters, and I've just reordered them a bit to make it simpler
for the
code expecting the parameters stay in the same order as in the spec
example
to parse them

Sergey


     Cheers,


  Jason


On Tue, Nov 19, 2013 at 1:36 AM, Sergey Beryozkin
<[email protected]

   wrote:



      Hi


  On 18/11/13 12:31, wang lei wrote:

     thanks for the quick reply.


  I found the token type was set to code by the
oauthClientManager.
After
changing it to token, I have managed to redirect the browser to
the
authorize.jsp. Once user allows the authorization, the form will
post
to
/decision which in turn will call the implicitGrantService.
createGrant.

Then I found at least 3 bugs in that service class. I will
raise a
jira
ticket to cxf later.

I understand that the implicit flow suggest there is no server
listening
the redirect for the client. But for mobile app it would be
fb00000://
and
localhost for browser app. I am only using your example to demo
the
idea.


     The mobile app is a public client but it has to be an
authorization

   code

flow, right ? You can use the authorization code flow for the
mobile
apps,
the authorization code service can be configured to support
public
clients

Sergey


      Cheers

    Jason

  On 19/11/2013 1:18 AM, "Sergey Beryozkin" <[email protected]

wrote:

      Hi


   Thanks for trying to make it work,

comments below
On 17/11/13 11:52, wang lei wrote:

      Hi all,


   I am trying to design a set of server APIs to follow the
oauth

implicit
flow. My main referring document is this one
http://cxf.apache.org/docs/jax-rs-oauth2.html. I am using the
sample
project at
https://github.com/Talend/tesb-rt-se/tree/master/
examples/cxf/jaxrs-oauth2as
the starting point.

It seems to me it would be a simple task to modify the sample
app to
use
the implicit flow instead of the authorization grant flow.

I updated the socialApp.xml to use the implicitGrantService

         <bean id="oauthAuthorizeService"

        class="org.apache.cxf.rs.security.oauth2.services.
ImplicitGrantService
        ">
                <property name="dataProvider"
ref="oauthProvider"/>
            </bean>

and then the restaurantReserve.xml to use the corresponding
endpoint
for
the new flow:

          <bean id="oauthClient" class="oauth2.thirdparty.
OAuthClientManager">
                <!--changed to use authrorize-implicit-->
                <property name="authorizationURI" value="
http://localhost
:
${http.port}/services/social/authorize-implicit"/>
                <property name="accessTokenService"
ref="atServiceClient"/>
            </bean>

After those changes, I expected some errors, most likely in
the
client
side
in the restauranatReserveServiceClass. As I can see it
expects
the
authorize code to exchange for access toke.

However, the error I got is unsupported_response_type.

Sample response:

Headers: {Location=[
http://localhost:8080/services/reservations/reserve/
complete#state=1&error=unsupported_response_type
]

I debugged the code and found out that the response_type=code,
whereas
the
supported type is token.

I then changed back to authorizationGrant, only found that the
response_type is still code but the supported type matches.

I understand the error -- "code" might mean the authorization
code,
which
is the 1st step in the authorization flow.

But I have no idea how the response_type is set and by whom.

       Implicit Grant Servuce returns this error because it can
not
support

     returning the access token as requested by the client via
presenting

   a

response_code 'code' which implies redirecting the user back to
the
client
server: this server is not available in the implicit flow, the
client
is
typically a gadget of some sort which runs directly in the end
user's
browser

       Any help will be appreciated. It would be idea if there
is a
working

     example for such flow.



      I think it would be a good idea to expand that demo a bit
but
I've
no a

    ready to show implicit code client at the moment - I know
some

  users
did
run CXF with the implicit flow, but have no more info.

The first step is to assume the client server is not there,
please
check
Google, I'm sure there will be some examples showing a client
script
running as an implicit code flow consumer withing a browser,
I'll
work
at
some later time on improving the demo

Thanks, Sergey


       Many thanks,




      --

   Sergey Beryozkin


Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com




     --


  Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com








  --
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com








--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com



Reply via email to