You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by daviesd <da...@oclc.org> on 2011/12/06 23:19:51 UTC
OAUTH2 ClientAuthenticationHandler: No access to security token
Argh! Not so great. The security token seems to be null even though I see
the st param on the makeRequest call.
I don¹t see any way inside of my ClientAuthenticationHandler to get at the
original request object or the security token. This presents a bit of a
problem for me, since we need to pass along a bit of information from the
token onto the authorization code request.
Ideas?
doug
On 12/6/11 10:02 AM, "daviesd" <da...@oclc.org> wrote:
> I didn¹t notice that the request coming into addOAuth2Authentication wasn¹t a
> HttpServletRequest but instead a org.apache.shindig.gadgets.http.HttpRequest
> with a securityToken accessor. Great!
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
We were having the same discussion here. Stayed tune... I have my project
for tomorrow. :)
doug
On 12/8/11 3:50 PM, "Li Xu" <le...@gmail.com> wrote:
> I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
> be helpful...It could provide a function to generate parameter based on
> HttpRequest. The default implemenation doesn't have to generate any
> parameter.
>
> thanks,
> li
>
>>
>>
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
>
> Sorry for the late reply. yes, please do. Please close the review and JIRA
> issue.
>
Thanks,
Li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
Li, revision submitted. Cleaned up the code to use Maps, used the Eclipse
formatters, and added a junit test.
Thanks for your help.
doug
On 12/12/11 3:10 PM, "Li Xu" <le...@gmail.com> wrote:
> ah, I see, no worry. I can clean up the code style when committing it.
> thanks.
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
Li. Thanks again for committing my changes. This is gonna really help our
implementation. Do I need to close out the review and jira?
doug
On 12/12/11 3:10 PM, "Li Xu" <le...@gmail.com> wrote:
> ah, I see, no worry. I can clean up the code style when committing it.
> thanks.
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
ah, I see, no worry. I can clean up the code style when committing it.
thanks.
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Doug if you want to create ones for IntelliJ and contribute them back we
would welcome them :) Might be something to consider if you plan on
contributing more code down the line.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: daviesd <da...@oclc.org>
To: <de...@shindig.apache.org>,
Date: 12/12/2011 02:54 PM
Subject: Re: OAUTH2 ClientAuthenticationHandler: No access to
security token
Awesome Li! As far as the code style comment. I'm an IntelliJ person.
Anyone have the templates for that? If not, I'll see about moving over to
Eclipse to do the edits.
doug
On 12/12/11 2:50 PM, "Li Xu" <le...@gmail.com> wrote:
> Thanks for the patch, Doug! It looks pretty good to me. only a few minor
> things I have added to the review.
> Thanks!
> li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
Awesome Li! As far as the code style comment. I'm an IntelliJ person.
Anyone have the templates for that? If not, I'll see about moving over to
Eclipse to do the edits.
doug
On 12/12/11 2:50 PM, "Li Xu" <le...@gmail.com> wrote:
> Thanks for the patch, Doug! It looks pretty good to me. only a few minor
> things I have added to the review.
> Thanks!
> li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
Thanks for the patch, Doug! It looks pretty good to me. only a few minor
things I have added to the review.
Thanks!
li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Dan Dumont <dd...@us.ibm.com>.
You may need to tell your SVN client to add them to source control
Then create the patch and make sure they are selected. (if you're using
eclipse, that's what I use)
From: daviesd <da...@oclc.org>
To: <de...@shindig.apache.org>,
Date: 12/12/2011 11:38 AM
Subject: Re: OAUTH2 ClientAuthenticationHandler: No access to
security token
Hmmm... I included 2 NEW files in the diff, but they didn't get added to
the
review. How do I do this?
doug
On 12/12/11 11:18 AM, "daviesd" <da...@oclc.org> wrote:
> I have submitted a revision to the review (3064) that implements the
> OAuth2RequestParameterGenerator class. I look forward to your responses
and
> getting this integrated as quickly as possible.
>
> Thanks for the guidance,
> doug
>
>
> On 12/8/11 3:50 PM, "Li Xu" <le...@gmail.com> wrote:
>
>> I see. Just a thought, Inject an OAuth2RequestParameterGenerator here
might
>> be helpful...It could provide a function to generate parameter based on
>> HttpRequest. The default implemenation doesn't have to generate any
>> parameter.
>>
>> thanks,
>> li
>>
>>>
>>>
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
Hmmm... I included 2 NEW files in the diff, but they didn't get added to the
review. How do I do this?
doug
On 12/12/11 11:18 AM, "daviesd" <da...@oclc.org> wrote:
> I have submitted a revision to the review (3064) that implements the
> OAuth2RequestParameterGenerator class. I look forward to your responses and
> getting this integrated as quickly as possible.
>
> Thanks for the guidance,
> doug
>
>
> On 12/8/11 3:50 PM, "Li Xu" <le...@gmail.com> wrote:
>
>> I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
>> be helpful...It could provide a function to generate parameter based on
>> HttpRequest. The default implemenation doesn't have to generate any
>> parameter.
>>
>> thanks,
>> li
>>
>>>
>>>
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
I have submitted a revision to the review (3064) that implements the
OAuth2RequestParameterGenerator class. I look forward to your responses and
getting this integrated as quickly as possible.
Thanks for the guidance,
doug
On 12/8/11 3:50 PM, "Li Xu" <le...@gmail.com> wrote:
> I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
> be helpful...It could provide a function to generate parameter based on
> HttpRequest. The default implemenation doesn't have to generate any
> parameter.
>
> thanks,
> li
>
>>
>>
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
be helpful...It could provide a function to generate parameter based on
HttpRequest. The default implemenation doesn't have to generate any
parameter.
thanks,
li
>
>
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
I guess my disconnect is that OUR implementation of the GrantRequestHandler
used the security token to PULL OUT the value we needed. In other words our
container had set the security token with trustedJson that held the extra
parameters we needed. Thus when the intial makeRequest happened, the 'st'
param went along for the ride.
Now we are saying we should just pull all the request parameters off of the
incoming makeRequest. Problem is it's initiated by the gadget, which
doesn't have knowledge of the value we stored in the security token. The
security token was my communication between the container and the gadget.
For the generic case I'd have to BLINDLY pass along ALL the parameters to
the authorization request (if we wanted a generic solution). I hate writing
a GrantRequestHandler that is specific to a provider (although that's
basically what I did to transition our parameter along), but if I don't know
what parameters to pass along I'm not sure how to generically do this.
I have to give this more thought.
doug
On 12/8/11 2:44 PM, "Li Xu" <le...@gmail.com> wrote:
> Hi Doug,
> Sure, np.
> Yes, it's hard to filter the parameter. Maybe all the query parameters as a
> first step?
>
> NO need to say sorry... we have all been new to Shindig once before. Let's
> still use the same issue and review request to keep track of this. When a
> new patch is ready, please just upload the patch in the review request.
>
> Thanks!
> li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
Hi Doug,
Sure, np.
Yes, it's hard to filter the parameter. Maybe all the query parameters as a
first step?
NO need to say sorry... we have all been new to Shindig once before. Let's
still use the same issue and review request to keep track of this. When a
new patch is ready, please just upload the patch in the review request.
Thanks!
li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by A Clarke <cl...@gmail.com>.
I agree with Li's suggested approach.
Making the request parameters available on the OAuth2Accessor means they'll
be generally available to all the different handlers/phases of the OAuth2
flow. Plus it doesn't require signature changes on the handler interfaces,
which is nice.
On Thu, Dec 8, 2011 at 2:24 PM, Li Xu <le...@gmail.com> wrote:
> Hi, Mike
>
> Thanks for the usecase. It makes sense to me and it could be quite common
> to have vendor specific extension parameters. Just think we may need a
> generic way to support that for both authorization endpoint and token
> endpoint...
>
> Here's a suggestion...
> Pass in real request parameters from HttpRequest into OAuth2Accessor as a
> Map. This can be set under BasicOAuth2Request.fetch function just before
> attemptFetch.
> Then it will be available for all the endpoint to use for the whole OAuth2
> flow.
>
> Thanks,
> li
>
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
Thanks Li. That was my initial implementation (to add something to the
accessor). However I backed off because I was trying to be the least
intrusive.
Mike and I will go back and see if there is a better way to do this. Just
not sure how you'd make it generic enough to figure out what request
parameters need to transfer.
What should I do with the code review request in the meantime? Is there a
way to cancel it, change the code around, and resubmit. Sorry for my
ignorance. First time around doing this.
doug
On 12/8/11 2:24 PM, "Li Xu" <le...@gmail.com> wrote:
> Hi, Mike
>
> Thanks for the usecase. It makes sense to me and it could be quite common
> to have vendor specific extension parameters. Just think we may need a
> generic way to support that for both authorization endpoint and token
> endpoint...
>
> Here's a suggestion...
> Pass in real request parameters from HttpRequest into OAuth2Accessor as a
> Map. This can be set under BasicOAuth2Request.fetch function just before
> attemptFetch.
> Then it will be available for all the endpoint to use for the whole OAuth2
> flow.
>
> Thanks,
> li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
Hi, Mike
Thanks for the usecase. It makes sense to me and it could be quite common
to have vendor specific extension parameters. Just think we may need a
generic way to support that for both authorization endpoint and token
endpoint...
Here's a suggestion...
Pass in real request parameters from HttpRequest into OAuth2Accessor as a
Map. This can be set under BasicOAuth2Request.fetch function just before
attemptFetch.
Then it will be available for all the endpoint to use for the whole OAuth2
flow.
Thanks,
li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Michael Matthews <ma...@oclc.org>.
Hi Li.
Doug and I work at the same organization.
We have an application where users authenticate and are associated with an
organization. There is contextual data that our application puts in
Shindig's SecurityToken via it's trustedJson field. One of these fields is
an identifier for the user's organization.
Our identity management team is developing an OAuth2 authorization server
and are requesting that we pass some of this contextual data to the
authorization server when Shindig makes the request to the authorization url
for an authorization grant. Their request seems reasonable as section 8.2 of
the OAuth2 spec suggests that additional vendor-specific parameters can be
passed to the authorization url.
This patch would allow parameters to be appended to the authorization grant
request by passing them on the query string.
Maybe there's a better way for the Shindig container to communicate
additional parameters at runtime on a authorization request?
Thanks
Mike
On 12/7/11 4:57 PM, "Li Xu" <le...@gmail.com> wrote:
> Doug,
> Thanks for submit the review request.
> Would you please elaborate your usecase why you need to pass additional
> parameter to authorization url? would like to understand how common is the
> usecase.
> thanks,
> li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
Doug,
Thanks for submit the review request.
Would you please elaborate your usecase why you need to pass additional
parameter to authorization url? would like to understand how common is the
usecase.
thanks,
li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Li Xu <le...@gmail.com>.
Thanks, Doug! Please remove the demo code from the patch and create a
review request. Thanks!
li
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by Dan Dumont <dd...@us.ibm.com>.
Hey, thanks for the patch, Doug!
Could you also sign up for an account at https://reviews.apache.org and
create a review request for the patch?
It's pretty straight forward, you just tell it which project and supply
the patch with the repo that it was created against.
Then fill out the form as best as possible linking the bug name and
filling in shindig for the group (so the dev list gets the review
request).
This should help people see the patch changes and understand them more
easily.
If you get stuck, just fire out an email here asking for help.
From: daviesd <da...@oclc.org>
To: shindig <de...@shindig.apache.org>,
Date: 12/07/2011 12:08 PM
Subject: Re: OAUTH2 ClientAuthenticationHandler: No access to
security token
I¹m not 100% sure of how I submit a patch as a non-committer, but I¹ve
created
https://issues.apache.org/jira/browse/SHINDIG-1672
with a proposed patch for this issue.
Essentially it passes the HttpRequest object along to the
GrantRequestHandler so that it has access to things like the security
token.
This is necessary in our implementation because we need to pass along
values
from our trusted json within the security token to our request for the
authorization code.
In the meantime we are maintaining our own version of the
BasicOAuth2Request
class and injecting our own implementation of the CodeGrantTypeHandler.
If/when this gets integrated into shindig trunk we¹ll switch over.
Thanks,
doug
On 12/6/11 6:48 PM, "daviesd" <da...@oclc.org> wrote:
> I see where my misunderstanding was. I thought the
> ClientAuthenticationHandler was called to set authentication values
before the
> authorization code request, based on this link (it¹s misleading).
>
> http://docs.opensocial.org/display/OSD/Client+Authentication
>
>> "Allows shindig developers to inject a new OAuth 2.0 Client
Authentication
>> handler into the flow to add authentication headers/etc. to all
requests to
>> the authorization and token enpoints for a provider."
>
> This does not appear to be the case. It looks like the
GrantRequestHandler is
> the appropriate place to add parameters you need before the
authorization code
> request happens.
>
> However BasicOAuth2Request does not pass along the original request
(from the
> makeRequest) nor the security token. It calls
>
> grantRequestHandlerUsed.getCompleteUrl(accessor);
>
> but the accessor doesn't have any of this info. I'll look into what it
would
> take to "patch" the code in order for the handler to have access to the
> original request or security token.
>
> doug
>
> On 12/6/11 5:19 PM, "daviesd" <da...@oclc.org> wrote:
>
>> Argh! Not so great. The security token seems to be null even though I
see
>> the st param on the makeRequest call.
>>
>> I don¹t see any way inside of my ClientAuthenticationHandler to get at
the
>> original request object or the security token. This presents a bit of
a
>> problem for me, since we need to pass along a bit of information from
the
>> token onto the authorization code request.
>>
>> Ideas?
>>
>> doug
>>
>>
>> On 12/6/11 10:02 AM, "daviesd" <da...@oclc.org> wrote:
>>
>>> I didn¹t notice that the request coming into addOAuth2Authentication
wasn¹t
>>> a HttpServletRequest but instead a
>>> org.apache.shindig.gadgets.http.HttpRequest with a securityToken
accessor.
>>> Great!
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
I¹m not 100% sure of how I submit a patch as a non-committer, but I¹ve
created
https://issues.apache.org/jira/browse/SHINDIG-1672
with a proposed patch for this issue.
Essentially it passes the HttpRequest object along to the
GrantRequestHandler so that it has access to things like the security token.
This is necessary in our implementation because we need to pass along values
from our trusted json within the security token to our request for the
authorization code.
In the meantime we are maintaining our own version of the BasicOAuth2Request
class and injecting our own implementation of the CodeGrantTypeHandler.
If/when this gets integrated into shindig trunk we¹ll switch over.
Thanks,
doug
On 12/6/11 6:48 PM, "daviesd" <da...@oclc.org> wrote:
> I see where my misunderstanding was. I thought the
> ClientAuthenticationHandler was called to set authentication values before the
> authorization code request, based on this link (it¹s misleading).
>
> http://docs.opensocial.org/display/OSD/Client+Authentication
>
>> "Allows shindig developers to inject a new OAuth 2.0 Client Authentication
>> handler into the flow to add authentication headers/etc. to all requests to
>> the authorization and token enpoints for a provider."
>
> This does not appear to be the case. It looks like the GrantRequestHandler is
> the appropriate place to add parameters you need before the authorization code
> request happens.
>
> However BasicOAuth2Request does not pass along the original request (from the
> makeRequest) nor the security token. It calls
>
> grantRequestHandlerUsed.getCompleteUrl(accessor);
>
> but the accessor doesn't have any of this info. I'll look into what it would
> take to "patch" the code in order for the handler to have access to the
> original request or security token.
>
> doug
>
> On 12/6/11 5:19 PM, "daviesd" <da...@oclc.org> wrote:
>
>> Argh! Not so great. The security token seems to be null even though I see
>> the st param on the makeRequest call.
>>
>> I don¹t see any way inside of my ClientAuthenticationHandler to get at the
>> original request object or the security token. This presents a bit of a
>> problem for me, since we need to pass along a bit of information from the
>> token onto the authorization code request.
>>
>> Ideas?
>>
>> doug
>>
>>
>> On 12/6/11 10:02 AM, "daviesd" <da...@oclc.org> wrote:
>>
>>> I didn¹t notice that the request coming into addOAuth2Authentication wasn¹t
>>> a HttpServletRequest but instead a
>>> org.apache.shindig.gadgets.http.HttpRequest with a securityToken accessor.
>>> Great!
Re: OAUTH2 ClientAuthenticationHandler: No access to security token
Posted by daviesd <da...@oclc.org>.
I see where my misunderstanding was. I thought the
ClientAuthenticationHandler was called to set authentication values before
the authorization code request, based on this link (it¹s misleading).
http://docs.opensocial.org/display/OSD/Client+Authentication
> "Allows shindig developers to inject a new OAuth 2.0 Client Authentication
> handler into the flow to add authentication headers/etc. to all requests to
> the authorization and token enpoints for a provider."
This does not appear to be the case. It looks like the GrantRequestHandler
is the appropriate place to add parameters you need before the authorization
code request happens.
However BasicOAuth2Request does not pass along the original request (from
the makeRequest) nor the security token. It calls
grantRequestHandlerUsed.getCompleteUrl(accessor);
but the accessor doesn't have any of this info. I'll look into what it
would take to "patch" the code in order for the handler to have access to
the original request or security token.
doug
On 12/6/11 5:19 PM, "daviesd" <da...@oclc.org> wrote:
> Argh! Not so great. The security token seems to be null even though I see
> the st param on the makeRequest call.
>
> I don¹t see any way inside of my ClientAuthenticationHandler to get at the
> original request object or the security token. This presents a bit of a
> problem for me, since we need to pass along a bit of information from the
> token onto the authorization code request.
>
> Ideas?
>
> doug
>
>
> On 12/6/11 10:02 AM, "daviesd" <da...@oclc.org> wrote:
>
>> I didn¹t notice that the request coming into addOAuth2Authentication wasn¹t a
>> HttpServletRequest but instead a org.apache.shindig.gadgets.http.HttpRequest
>> with a securityToken accessor. Great!