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 > > 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]
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
