I think its true to some extent that some OAuth authorization servers (AS) use their own configuration parameters and also some what deviate from the OAuth specification.
What you can do is - keep a basic OAuth 1.0 and 2.0 modules and if you see a given AS has changed the behavior - extend from the correct OAuth module and add the specific behavior there. Thanks & regards, -Prabath On Thu, Sep 25, 2014 at 10:23 AM, Johann Nallathamby <[email protected]> wrote: > > > On Thu, Sep 25, 2014 at 9:24 AM, Ravindra Ranwala <[email protected]> > wrote: > >> The constraints we encountered are listed below. >> >> Different OAuth Providers use different OAuth versions. >> > > Yes. There are two versions 1.0a and 2.0. You don't have any way around > this because some providers still use 1.0a. > > >> Different OAuth Providers expose different APIs and different >> configuration details. >> > > This cannot be true. If they are spec compliant they should expose a > standard set of endpoints. E.g. for oauth10a there are 3 standard > endpoints, for oauth2 there are two standard endpoints. > > And since OAuth is a transport level security protocol it should be very > easy to extract all the authorization logic out from the connector. E.g. > the Bearer access token goes as part of the Authorization header, which > means you should be able to set it to the transport header and ESB should > handle it in sending it out with the request if I am not mistaken. The > connector should not worry about setting these headers even. It's the same > for oauth1.0a, except that the message in the header is more complex. > > Can you be more specific when you say different APIs and different > configurations? What you need to see is if they comply with standard OAuth > or not. > >> >> This makes it bit difficult to generalize the Authorization process >> across different OAuth Providers. >> >> Thanks & Regards, >> >> On Thu, Sep 25, 2014 at 8:58 AM, Johann Nallathamby <[email protected]> >> wrote: >> >>> +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>* >>> >> >> >> >> -- >> 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 >> >> > > > -- > 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 > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +94 71 809 6732 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
