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
