[Fiware-technical-committee] [FIWARE Security] Token exchange

[Federico Michele Facca]

Hi Alvaro, All,

few considerations:

1. secret disclosure is not needed, you need to disclose the client_id that will be used as “audience” (if you would need to disclose the secret, you could use a normal oauth protocol)   
    translated: the wilma protecting CP2 to allow CP1 to query CP2 will only need to know CP1 client id (and of course CP2 client
    and secret, but i suppose this also the case now).
2. token exchange is meant to support also exchange with external IDP (two different keyrock, or a keyrock and any other idp implementing the standard)
3. token exchange allows user impersonation (quite useful especially when linking different idp)
4. it’s a standard :)

as stated previously, I am not in favour of ad-hoc solutions when there are standards.

Best,
Federico



> On 8 Oct 2018, at 12:15, Álvaro Alonso <aalonsog at dit.upm.es> wrote:
> 
> Hi all, I’ve been reading the Token exchange draft Federico shared with us in order to compare this feature with the current one supported by Keyrock, the Trusted applications feature. Here are my impressions:
> 
> Let’s imagine a scenario in which Context Provider 1 (CP1) is exposing an entity that is actually provided by Context Provider 2 (CP2). Using both approaches CP1 administrator has to define in Keyrock UI the needed roles and permissions to access the entity and assign them to the user that will consume it. Then:
> 
> - In case using Trusted applications feature, the next step to be performed by CP2 administrator is to add in Keyrock UI the identifier of CP1 application as one of its trusted applications. Thus, when the PEP Proxy deployed in CP2 tries to validate the received token from CP1, Keyrock validates it. 
> 
> - In case using Token exchange feature, the next step to be performed by CP1 is to insert the client and secret identifiers of CP2 application in its logic to be able to create OAuth tokens. Thus, when trying to validate a token received from CP1, CP2 will create a new token with the user credentials but scoped in CP2 application. 
> 
> As you can see both approaches solves the problem. However, the process to enable it in the Context Providers is different an implies the sharing of some data between both of them. In case using Trusted applications, CP2 has to know only the id of the Context providers are going to access entities stored by it. On the other hand, when using Token exchange, CP1 has to know the client id and secret of every Context Provider it will access to. Of course this is sensitive information I’m not sure it is feasible to share between them. Furthermore, using this approach Context Providers have to implement OAuth standard to be able to create access tokens. This is a thing could be provided by PEPs if we implement it (in Wilma, API Umbrella, etc) but that includes an extra load (and extra requests) in those components. Using Trusted applications all the work is done in Keyrock, Clients and services are not aware of the process.
> 
> My conclusion is that the use of Token exchange is better in terms of using a standard (taking into account that currently it is just a draft that has not necessary to be accepted as part of the specification) but implies to add complexity in the PEPs implementation and the sharing of the secret credentials of the applications. Trusted applications just needs to share the identifier of the applications and the extra load is totally balanced to Keyrock. 
> 
> My opinion is that we could continue using Trusted applications feature by now and to discuss other approaches in the future.
> 
> What do you think?  
> --
> Álvaro
> 
> __________________________________________________________________________________________
> 
> You can get more information about our cookies and privacy policies on the following links:
> - http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Privacy_Policy
> - http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Cookies_Policy_FIWARE
> 
> Fiware-technical-committee mailing list
> Fiware-technical-committee at lists.fiware.org
> https://lists.fiware.org/listinfo/fiware-technical-committee
> 

Dr. FEDERICO MICHELE FACCA
Head of Martel Lab
0041 78 807 58 38
Martel Innovate <https://www.martel-innovate.com/>  -  Professional support for innovation projects 
Click to download our innovators' insights! <https://www.martel-innovate.com/premium-content/> 
Follow Us on Twitter <https://twitter.com/Martel_Innovate>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-technical-committee/attachments/20181009/fb0ab164/attachment.html>