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
