Hi Farasath, On Thu, Apr 25, 2019 at 9:26 AM Farasath Ahamed <farasa...@wso2.com> wrote:
> > > On Thu, Apr 25, 2019 at 7:32 AM Johann Nallathamby <joh...@wso2.com> > wrote: > >> Hi Malithi, >> >> On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe <malit...@wso2.com> >> wrote: >> >>> >>> >>> 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 >>> >> >> Using the access token to authenticate the client at the resource server >> is one of the design principle behind OAuth2 right? >> > > What do we mean by the client here? is it the OAuth client or the end user? > OAuth2 client. The application or service provider. > In both cases, there is no *authentication* when the token is presented > at the resource server > *There is authentication*. The client is authenticating to the resource server by means of the access token. The bearer token is a reference token that refers to the client's client_id. You can't be authorized unless you have been authenticated. > (In our case resource server is the REST valve and authorization server is > IS), isn't it? > Yes, correct. > > 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. >> > > This is not entirely correct. > > Since 'username' is optional based on privacy concerns we already have > requests for the possibility of masking the user information from the > introspection response. If we decide to support masking the user > information, then this current design of extracting user information based > on introspection response will break. > How do you plan to mask? If by masking you mean introducing an opaque identifier for the user, that won't impact this design. The the authorization also will be based on the new opaque identifier. Similar discussion I brought up on [1] as well. > Also, we need to think about user consent on sharing claims/attributes in > introspection response too. We do not have this at the moment but we might > need to support it in future. Since the username is optional in > introspection response, it can be returned or not based on user consent. > This would break once again break the current design. > This has already been reported [2]. [1] "[IAM] Recommendation on WSO2 Usernames and Login names" in support-dev-gr...@wso2.com [2] https://support.wso2.com/jira/browse/SECINTDEV-212 Thanks & Regards, Johann. > > >> >>> 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 <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 >>> >> >> >> -- >> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | >> WSO2 Inc. >> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >> [image: Signature.jpg] >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> > > > -- > 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> > > > > -- *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | WSO2 Inc. (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com [image: Signature.jpg]
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
