Hi All,
According to current status, we need to do this with connectors.
So, through this mail, I would like to propose a probable solution on this.
There'll be two new entries for 'init' section of a connector. So, in
generic case a init of a connector should looks like follows:
<connector_name.init>
<consumerKey>{wso2:vault-lookup('xx.consumerKey')}</consumerKey>
<consumerSecret>xx</consumerSecret>
<accessToken>{wso2:vault-lookup('xxx.oauth.accessToken')}</accessToken>
*<refreshToken>{wso2:vault-lookup('xxx.oauth.refreshToken')}</refreshToken>*
* <tokenTimeout>10</tokenTimeout>*
</connector_name.init>
Those 2 new parameters could be optional depending on the connector. In
brief,
* refreshToken - The refresh token obtain from a service
* tokenTimeout - Time-to-live of an access token. This could have a default
value (eg: 3600 seconds)
So the flow should be as follows:
1. A message comes to init phase
2. check (the last access-token update time + token-timeout) against
current time
3. if (the last access-token update time + token-timeout) > current time,
message can go ahead since token has not expired.
4. if (the last access-token update time + token-timeout) < current time,
then access-token needs to update (may be refresh-token too, depending on
the service). Update the access-token. Keep track of the updated time &
update in-memory synapse configuration accordingly.
One doubtful thing I found while developing the story is, where to store
the last token-updated-time (it also needs restricted to a tenant). My
suggestion for that is a local-entry unique to a connector.
The reason behind introducing tokenTimeout is, different services expire
access-token in different time-periods, so this will enable users to adjust
expiration-timeout accordingly.
Rather than implementing this functionality connector-wise, I prefer this
to have at an abstract level. Also please note that, according to OAuth 2
Authorization Framework Spec. (RFC 6749), the request to get a new
access-token should follow a standard methodology.
So, I would like to hear your thoughts on this.
Thank you!
On Fri, Mar 6, 2015 at 5:51 PM, Vanjikumaran Sivajothy <[email protected]>
wrote:
> Hi Buddhima,
>
> As a interim solution i am proposing to have a update the connector with
> the separate functionality.
>
> However, currently there is another discussion on the architecture mailing
> list to add this functionality in existing Oauth mediator. I believe, we
> can reuse the given component for connector development too and currently
> we are evaluating that.
>
> [1][Architecture] Improve ESB OAuth Mediator to automatically renew token
>
> On Fri, Mar 6, 2015 at 5:43 PM, Buddhima Wijeweera <[email protected]>
> wrote:
>
>> Hi Vanji,
>>
>> Thank you for the answer.
>>
>> So the point not clear is, are you proposing to add this functionality
>> for each connector?
>> I think this should be done at a higher level and make it less affect to
>> connector implementation. If so, we'll be able to reduce the cost of
>> changing each and every connector.
>>
>> Also, I think this is a mandatory requirement for all connectors and
>> start with most frequently using connectors eg: Twitter, Gmail etc., since
>> this is to make connectors ready for long-running production ESB instances.
>>
>> Thank you!
>>
>>
>> On Fri, Mar 6, 2015 at 5:20 PM, Vanjikumaran Sivajothy <[email protected]>
>> wrote:
>>
>>> Hi Buddhima,
>>>
>>> Please see my answers in line
>>>
>>> Best Regards,
>>> Vanji
>>>
>>>
>>>
>>> On Tue, Mar 3, 2015 at 8:34 PM, Buddhima Wijeweera <[email protected]>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> This is regarding OAuth token expiration and using Refresh Token for
>>>> updating the Access Token.
>>>>
>>>> *Problem:*
>>>> This problem currently emerged from ESB Connectors. After configuring a
>>>> connector according to documentation, it works fine for certain time and
>>>> become not usable.
>>>>
>>>> *Reason:*
>>>> Within the init of a connector we provide an Access Token. That Access
>>>> Token will have an expiration time. So after expiration time, the connector
>>>> will not be usable.
>>>>
>>>> *Explanation:*
>>>> After a successful OAuth flow we receive an Access Token & a Refresh
>>>> Token from the service. But within the current implementation of connectors
>>>> the Refresh Token is not being used. According to OAuth 2 Authorization
>>>> Framework Spec. (RFC 6749), at section "Refreshing an Access Token"
>>>> following type of request can be used to obtain a new Access Token.
>>>>
>>>> POST /token HTTP/1.1
>>>> Host: server.example.com
>>>> Authorization: Basic czZCaGRSa3FppppnWDFmQmF0M2JW
>>>> Content-Type: application/x-www-form-urlencoded
>>>>
>>>> grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
>>>>
>>>>
>>>>
>>>> Also, it is noted that server MAY issue a new Refresh token in the
>>>> response and client should renew the Refresh Token too.
>>>>
>>>> Since refreshing Access Token implementation is not in connector
>>>> implementation, connectors will not be usable for long running production
>>>> environment.
>>>>
>>>
>>> Your concern is 100% correct and we have already taken this into
>>> consider after our first released of the connectors. The most of the
>>> connectors that are implemented in recent past contain the Oauth flow. If
>>> you can point out the connectors that need to be improve. That would be
>>> helpful us to prioritize development process.
>>>
>>>
>>>>
>>>> So, your thoughts on this would be highly appreciated.
>>>>
>>>> Thank you!
>>>>
>>>> --
>>>> Buddhima Wijeweera
>>>> Software Engineer; WSO2 Inc.; http://wso2.com ,
>>>>
>>>> Mobile: +94 71 427 9966
>>>> Email: [email protected]
>>>> Blog: https://buddhimawijeweera.wordpress.com
>>>> GitHub Profile: https://github.com/Buddhima
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Sivajothy Vanjikumaran
>>> *Senior Software Engineer*
>>> *Integration Technologies Team*
>>> *WSO2 Inc. http://wso2.com <http://wso2.com/>*
>>> *Mobile:(+94)777219209*
>>> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image:
>>> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn]
>>> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image:
>>> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare]
>>> <http://www.slideshare.net/vanjikumaran>
>>>
>>> This communication may contain privileged or other
>>> confidential information and is intended exclusively for the addressee/s.
>>> If you are not the intended recipient/s, or believe that you may
>>> have received this communication in error, please reply to the
>>> sender indicating that fact and delete the copy you received and in
>>> addition, you should not print, copy, re-transmit, disseminate, or
>>> otherwise use the information contained in this communication.
>>> Internet communications cannot be guaranteed to be timely, secure, error
>>> or virus-free. The sender does not accept liability for any errors
>>> or omissions
>>>
>>
>>
>>
>> --
>> Buddhima Wijeweera
>> Software Engineer; WSO2 Inc.; http://wso2.com ,
>>
>> Mobile: +94 71 427 9966
>> Email: [email protected]
>> Blog: https://buddhimawijeweera.wordpress.com
>> GitHub Profile: https://github.com/Buddhima
>>
>
>
>
> --
> Sivajothy Vanjikumaran
> *Senior Software Engineer*
> *Integration Technologies Team*
> *WSO2 Inc. http://wso2.com <http://wso2.com/>*
> *Mobile:(+94)777219209*
> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: Twitter]
> <https://twitter.com/vanjikumaran> [image: LinkedIn]
> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image:
> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare]
> <http://www.slideshare.net/vanjikumaran>
>
> This communication may contain privileged or other
> confidential information and is intended exclusively for the addressee/s.
> If you are not the intended recipient/s, or believe that you may
> have received this communication in error, please reply to the
> sender indicating that fact and delete the copy you received and in
> addition, you should not print, copy, re-transmit, disseminate, or
> otherwise use the information contained in this communication.
> Internet communications cannot be guaranteed to be timely, secure, error
> or virus-free. The sender does not accept liability for any errors
> or omissions
>
--
Buddhima Wijeweera
Software Engineer; WSO2 Inc.; http://wso2.com ,
Mobile: +94 71 427 9966
Email: [email protected]
Blog: https://buddhimawijeweera.wordpress.com
GitHub Profile: https://github.com/Buddhima
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
