On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby <joh...@wso2.com> wrote:
> First of all, I don't understand what is the design issue with using > OAuth2 as a handler in authenticating and authorizing access to Rest APIs > by a client? Isn't that what OAuth2 is meant for typically? > Why should an access token just be used to get the authenticated subject, and that is also from introspection where that username is optional Why not use the access token for authorization it self. Isn't that how OAuth2 should be used > > Secondly, I think if the use case contains secondary user stores and > client expects to call out product APIs like SCIM, it is not wrong to > expect to have the checkbox on for those service providers. I don't see a > big issue in having that expectation really. > > Regards, > Johann. > > On Wed, Apr 24, 2019 at 8:02 PM Malithi Edirisinghe <malit...@wso2.com> > wrote: > >> >> >> On Wed, Apr 24, 2019 at 4:42 PM Ruwan Abeykoon <ruw...@wso2.com> wrote: >> >>> Hi All, >>> Is that mean we use the same token to authentication(of the app) and >>> authorization (for the resource), both? >>> >> >> Well actually the case is, we have implemented a mechanism to allow >> access for resources (REST APIs) with an OAuth2 access token. >> Case is, this design is such that the access token is used to retrieve >> the user (from introspection), and rather than authorizing based on the >> access token, a separate authorization API is used to identify whether that >> respective user is authorized to the respective resource. >> >> >>> >>> Cheers, >>> Ruwan A >>> >>> On Wed, Apr 24, 2019 at 1:49 PM Malithi Edirisinghe <malit...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Wed, Apr 24, 2019 at 1:31 PM Farasath Ahamed <farasa...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Apr 24, 2019 at 1:23 PM Malithi Edirisinghe <malit...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Yes, the major problem here is using an oauth token to get the user >>>>>> realm and using it later for authorization. >>>>>> OAuth is for authorization, in that aspect IMO, we need to re-design >>>>>> this handler. >>>>>> >>>>>> However, to come across with present issue with less effort I have >>>>>> below suggestion. >>>>>> I think if it needs to pick up the user info, it should access the >>>>>> user info endpoint with the token and get the realm information from >>>>>> there >>>>>> (user store domain, tenant domain) and that info then can be used to >>>>>> authorize the user in latter means. >>>>>> >>>>> >>>>> So this means only OAuth tokens obtained with "openid" scopes can be >>>>> used for authentication at the REST valve right? >>>>> >>>> >>>> Yes. As this model expects authentication I think that would be a >>>> better way to proceed with the current one we have. Only a short term >>>> solution. >>>> >>>> >>>> Do we have realm information in user info response? IIRC we included >>>>> realm information in the id_token only with a recent fix. >>>>> >>>> >>>> Yes, that is correct. But, IMO, it is something good to be incorporated >>>> to user info. >>>> WDYT? >>>> >>>> >>>>> >>>>> Thanks, >>>>>> Malithi >>>>>> >>>>>> On Wed, Apr 24, 2019 at 12:58 PM Isuranga Perera <isura...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> All: >>>>>>> With regards $subject[1] >>>>>>> >>>>>>> Here we have authentication flow and authorization flow. Token >>>>>>> validation service is used at authentication and username is set by the >>>>>>> validator. However, when "Use user store domain in local subject >>>>>>> identifier" is not enabled in Local & Outbound Authentication >>>>>>> Configuration usernames of secondary user-store users are set >>>>>>> without the domain parameter. >>>>>>> Since the user realm is configured depending on the tenant name when >>>>>>> authorizing secondary user store users at Authorization Valve suffering >>>>>>> from a caching issue which resulted in permission update ignorance. >>>>>>> This issue is not affected to tenant users as the tenant is >>>>>>> explicitly appended to the username at the time of authentication. >>>>>>> >>>>>>> $subject can be overcome by enabling "Use user store domain in local >>>>>>> subject identifier" in Local & Outbound Authentication Configuration >>>>>>> >>>>>>> >>>>>>> However one of the main issues is OAuth token is used to >>>>>>> authenticate the user in AuthenticationValve. We have to reaccess the >>>>>>> validity of this design approach as well. >>>>>>> >>>>>>> >>>>>>> Please provide your feedback on the $subject. >>>>>>> >>>>>>> >>>>>>> [1] https://github.com/wso2/product-is/issues/5078 >>>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Isuranga Perera >>>>>>> >>>>>>> -- >>>>>>> *Isuranga Perera* | Software Engineer | WSO2 Inc. >>>>>>> +94 71 735 7034 | isura...@wso2.com <isu...@wso2.com> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Malithi Edirisinghe* >>>>>> Technical Lead >>>>>> WSO2 Inc. >>>>>> >>>>>> Mobile : +94 (0) 718176807 >>>>>> malit...@wso2.com >>>>>> >>>>> >>>>> >>>>> -- >>>>> Farasath Ahamed >>>>> Senior Software Engineer, WSO2 Inc.; http://wso2.com >>>>> Mobile: +94777603866 >>>>> Blog: https://farasath.blogspot.com / https://medium.com/@farasath >>>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>>> <http://wso2.com/signature> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> *Malithi Edirisinghe* >>>> Technical Lead >>>> WSO2 Inc. >>>> >>>> Mobile : +94 (0) 718176807 >>>> malit...@wso2.com >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>> >>> >> >> -- >> >> *Malithi Edirisinghe* >> Technical Lead >> WSO2 Inc. >> >> Mobile : +94 (0) 718176807 >> malit...@wso2.com >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> > > > -- > *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | > WSO2 Inc. > (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com > [image: Signature.jpg] > -- *Malithi Edirisinghe* Technical Lead WSO2 Inc. Mobile : +94 (0) 718176807 malit...@wso2.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
