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
