+1 to externalize the authorization logic. It will also help evolve the connectors when OAuth goes out of fashion and another authorization standard rules over it. What kind of difficulties did you come across? As long as it is following OAuth 1.0a or 2.0 standard you should be able to be able to generalize your code.
Thanks, Johann. On Thu, Sep 25, 2014 at 8:40 AM, Ravindra Ranwala <[email protected]> wrote: > In the iPAAS integration project for ESB, we are implementing OAuth > authorization support for different providers such as twitter, google, > salesforce, facebook,LinkedIn etc to access their resources from our iPAAS > app. Each provider has their own configuration details and APIs for this > purpose. So we found that it is very difficult to generalize our solution. > If you have any idea of generalizing the OAuth authorization process across > different OAuth service Providers please don't hesitate to share your ideas > with us. > > > > Thanks & Regards, > -- > Ravindra Ranwala > Software Engineer > WSO2, Inc: http://wso2.com > <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> > Mobile: +94714198770 > > -- > You received this message because you are subscribed to the Google Groups > "WSO2 Engineering Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/a/wso2.com/d/optout. > -- Thanks & Regards, *Johann Dilantha Nallathamby* Associate Technical Lead & Product Lead of WSO2 Identity Server Integration Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
