On Mon, Jun 3, 2019 at 5:29 PM Asela Pathberiya <[email protected]> wrote:
> > > On Mon, Jun 3, 2019 at 12:22 PM Johann Nallathamby <[email protected]> > 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. Thanks & Regards, Johann. > Thanks, > Asela. > > > >> Thanks & Regards, >> Johann. >> >> On Fri, May 31, 2019 at 9:43 AM Asela Pathberiya <[email protected]> wrote: >> >>> >>> >>> On Fri, May 31, 2019 at 7:58 AM Johann Nallathamby <[email protected]> >>> 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) [email protected] >>>> [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) [email protected] >> [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) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
