Hi All, Is that mean we use the same token to authentication(of the app) and authorization (for the resource), both?
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 >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
