Also please note that - Identity Server also has the concept of authenticators. Once you come up with a plan can we please do an API review.. Ideally we should be able to consume the authentication handler both in ESB and in IS...
Thanks & regards, -Prabath On Thu, Sep 25, 2014 at 11:35 AM, Ravindra Ranwala <[email protected]> wrote: > Hi All, > > Thanks a lot for the valuable feedback given. We'll consider all these > things when we implement this solution in our iPAAS. > > > Regards, > > > On Thu, Sep 25, 2014 at 11:08 AM, Prabath Siriwardena <[email protected]> > wrote: > >> According to the OAuth 2.0 Bearer Token Profile, when accessing a >> resource protected with OAuth 2.0, the bearer token can go in the HTTP >> Authorization header or be a form-encoded body parameter or a query >> parameter. If it’s a query parameter, its value must be access_token. But >> here, LinkedIn deviates from the OAuth 2.0 Bearer Token Profile. >> >> Following is a request to the LinkedIn UserInfo endpoint... >> >> curl >> https://api.linkedin.com/v1/people/~?oauth2_access_token=AQVKwPCyJoTDl9CZl5ID9S9hig9qd0P >> >> Thanks & regards, >> -Prabath >> >> >> >> On Thu, Sep 25, 2014 at 11:02 AM, Prabath Siriwardena <[email protected]> >> wrote: >> >>> 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 >>> >> >> >> >> -- >> 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 >> > > > > -- > 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, 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
