Hi Malithi, On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe <[email protected]> wrote:
> > > On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby <[email protected]> > 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 > Using the access token to authenticate the client at the resource server is one of the design principle behind OAuth2 right? And if the access token was obtained using client_credentials grant flow, the authenticated subject would be in fact the application owner in our implementation, which is also perfectly fine, because we don't intend to bring any other authorization server for this use case. Similarly relying on optional 'username' parameter of introspection response, is also perfectly fine IMO, because again we never intend to replace our authorization server with a 3rd party in this use case. > Why not use the access token for authorization it self. Isn't that how > OAuth2 should be used > With regards to authorization, OAuth2 specifies a way for the client to request authorization from authorization server and a way to delegate authorization to client by the authorization server, via scopes. However, how this authorization levels / scopes are interpreted is left to our desired implementation. It is the authorization server policy which decides what level of authorization the client will get, even if the client doesn't request for any scope. So in this use case our authorization server policy says, grant the authorization levels to the client based on the authorization levels (permissions) of the application owner. This means all the applications which are created by same user will inherit the same set of permissions from that user. Do you see a problem in assuming this policy? I haven't thoroughly thought through about the impact of this policy in a 3 legged OAuth2 grant flow for the use case of securing product APIs, in which case the authenticated subject will be the resource owner, and (s)he might have a different set of permissions than the application owner. But still I don't think it will create any issues with this policy. Do holler if you see any issue there. Hope I understood your concerns and hope I clarified them. Thanks & Regards, Johann. > >> >> 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 <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Apr 24, 2019 at 4:42 PM Ruwan Abeykoon <[email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Apr 24, 2019 at 1:31 PM Farasath Ahamed <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 24, 2019 at 1:23 PM Malithi Edirisinghe < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 | [email protected] <[email protected]> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Malithi Edirisinghe* >>>>>>> Technical Lead >>>>>>> WSO2 Inc. >>>>>>> >>>>>>> Mobile : +94 (0) 718176807 >>>>>>> [email protected] >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> [email protected] >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>> >>>> >>> >>> -- >>> >>> *Malithi Edirisinghe* >>> Technical Lead >>> WSO2 Inc. >>> >>> Mobile : +94 (0) 718176807 >>> [email protected] >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> 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) [email protected] >> [image: Signature.jpg] >> > > > -- > > *Malithi Edirisinghe* > Technical Lead > WSO2 Inc. > > Mobile : +94 (0) 718176807 > [email protected] > -- *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | WSO2 Inc. (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected] [image: Signature.jpg]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
