On Mon, Jun 3, 2019 at 6:28 PM Johann Nallathamby <joh...@wso2.com> wrote:
> > > On Mon, Jun 3, 2019 at 6:25 PM Johann Nallathamby <joh...@wso2.com> wrote: > >> >> >> On Mon, Jun 3, 2019 at 5:29 PM Asela Pathberiya <as...@wso2.com> wrote: >> >>> >>> >>> On Mon, Jun 3, 2019 at 12:22 PM Johann Nallathamby <joh...@wso2.com> >>> wrote: >>> >>>> Hi Asela, >>>> >>>> As of now I see 2 potential use cases for scope mappings. >>>> >>>> 1. There are two different RPs in an organization which are accessed by >>>> a partner. The application is configured for OpenID Connect delegated >>>> authentication with WSO2 IS in the organization and WSO2 IS is configured >>>> for OpenID Connect federation with the partner's in-house OP. The two RPs >>>> need to consume different set of attributes of the user from the partner >>>> OP. In this case scope mapping is needed to request attributes from >>>> federated OP. >>>> >>> >>> Yes this is fine. I also thought the same. But this also may be >>> limited use case as most of the OP may provide the usual attribute with >>> openid connect scope. >>> >>> >>>> >>>> 2. An application or api gateway or micro-service in the partner domain >>>> calls into our API gateway which is protected by OAuth2 in WSO2 IS. WSO2 IS >>>> is configured for token delegation to accept the partner's scoped access >>>> tokens and exchange it to our own scoped access tokens. In this case scope >>>> mapping is needed to issue access tokens with the corresponding restricted >>>> set of scopes. >>>> >>> >>> To be clear, I assume that this is to implement which is mentioned in >>> here [1] as scope ? >>> >>> [1] https://tools.ietf.org/html/rfc7521#section-4.1 >>> >> >> Sorry Asela, I actually got the term wrong. I was referring to "token >> exchange" not "token delegation". But I hope you understood the use case. >> Now token delegation can be implemented in multiple ways. >> 1. Custom grant flow to exchange an access token issued by a trusted >> authorization server to another token from a different authorization server >> 2. JWT grant flow to exchange a self-contained JWT access token issued by >> a trusted authorization server to another access token from a different >> authorization server >> 3. Token exchange spec - >> https://tools.ietf.org/id/draft-ietf-oauth-token-exchange-14.html >> > Thanks for clarification! > >> >> In all these implementations if the client has a token from one trusted >> domain domain and is planning to call a resource server in another domain >> which is protected by WSO2, then WSO2 must have scope mapping capability in >> order to translate the original scopes in the access token to scopes in its >> own domain. >> > > After the scopes are mapped they can be further authorized using XACML or > something else, but that is the next step. > > Regards, > Johann. > > >> Thanks & Regards, >> Johann. >> >> >>> Thanks, >>> Asela. >>> >>> >>> >>>> Thanks & Regards, >>>> Johann. >>>> >>>> On Fri, May 31, 2019 at 9:43 AM Asela Pathberiya <as...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, May 31, 2019 at 7:58 AM Johann Nallathamby <joh...@wso2.com> >>>>> wrote: >>>>> >>>>>> *Problem* >>>>>> >>>>>> When we federate to other OpenID Connect Providers, we can send scope >>>>>> values. However, currently the scope values are fixed per OP we define in >>>>>> IS. This works fine if the service provider is not a OpenID Connect RP or >>>>>> an RP not requesting scopes. If we are to support different scope >>>>>> combinations that can be requested by different RPs, it is not scalable >>>>>> to >>>>>> define individual OP configurations for each scope combination. >>>>>> >>>>>> *Solution* >>>>>> >>>>>> We must support scope mappings, so that we can map a set of scopes >>>>>> requested by the RP to another set of scopes supported by the OP. This >>>>>> way >>>>>> we don't need to create multiple OP configurations to support different >>>>>> scope combinations requested by different RPs. >>>>>> >>>>>> What are your thoughts on this? >>>>>> >>>>> >>>>> I am just wondering why does RP need to send different scopes to >>>>> federated IDP ? Is it just to retrieve different attributes from >>>>> id_token or userinfo attributes based on RP ? If it is not, is there any >>>>> other use cases ? >>>>> >>>>> Thanks, >>>>> Asela. >>>>> >>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Johann. >>>>>> >>>>>> -- >>>>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions >>>>>> Architect | WSO2 Inc. >>>>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>>>>> [image: Signature.jpg] >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Asela >>>>> >>>>> Mobile : +94 777 625 933 >>>>> >>>>> http://soasecurity.org/ >>>>> http://xacmlinfo.org/ >>>>> >>>> >>>> >>>> -- >>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect >>>> | WSO2 Inc. >>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>>> [image: Signature.jpg] >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> Mobile : +94 777 625 933 >>> >>> http://soasecurity.org/ >>> http://xacmlinfo.org/ >>> >> >> >> -- >> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | >> WSO2 Inc. >> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >> [image: Signature.jpg] >> > > > -- > *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | > WSO2 Inc. > (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com > [image: Signature.jpg] > -- Thanks & Regards, Asela Mobile : +94 777 625 933 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
