Send Issuer and Subject and maybe AccessToken with LUMA request

[bwegh]

As discussed in Lisbon the call to LUMA MUST include the OpenID Connect Issuer and Subject,
the access token is nice to have and needed for some cases, yet I would have it configurable and off by default, just from a security point of view.

please also add examples of the json arriving at LUMA to the Readme.

I added this issue to keep track of the current state of it, to know when to adjust luma for KIT.

[bwegh]

any update on this issue?

[luman75]

Version 17.06.0-beta4 should be solving the issue.

Oneprovider will pass the following structure
user: id name oauth_accounts: google: id name github: id name

and the user id will be encoded Issuer and Subject.
For instance google:2732828237afe72222323232

Where google is a name defined in Onezone auth.config for google IdP and it's fixed.

In regards to the other issue passing AccessToken obtained from third party might lead to security breach as user not necessarily can trust Oneprovider, he should only trust to Onezone he's login trough. So we are not planning to deliver such information to LUMA.

[bwegh]

In the Issue and discussion we said "OpenID Connect Issuer and subject", but this implements some string and subject, nothing that relates in any form to other OpenID Connect issuer subject as

google != https://accounts.google.com

so how can luma lookup google and receive https://accounts.google.com?
and is the assumption correct, that 2732828237afe72222323232 is the subject at https://accounts.google.com?

which version of onedata is needed to provide the luma interface?

[bwegh]

In regards to the other issue passing AccessToken obtained from third party might lead to security
breach as user not necessarily can trust Oneprovider, he should only trust to Onezone he's login
trough. So we are not planning to deliver such information to LUMA.

That sounds not good, if a user can not necessarily trust a OneProvider, maybe a trustchain from OneZone can help here?

[luman75]

@bwegh user can trust all providers who works with but we don't want to assue that he needs to do that.

Our current model assumes that:

1. User trusts selected zone
2. Owner of data space needs to trust all providers supporting he's spaces
3. Users granted access to selected data spaces do not need to trust all the providers supporting all the spaces he has access to.

This has some conceptual implications about data flow in the system etc, and gives us more mobility on users data.

That's the background story behind the issue.

[bwegh]

thanks for clarifying @luman75 ,

what about the lookup of google -> https://accounts.google.com from a LUMA endpoint?
and which version of OneData needs to be used for this feature to be present?

[luman75]

@bwegh this is actually a very good question. Currently this information is set in auth.config file in onezone.
auth.config

So for now you need to get this information directly from a sysadmin of the zone you are working with, beyond system API. But we can create a simple REST API to make this query be supported via programatic application interfaces. Not sure if such thing really matters enough to be covered by REST API.

[groundnuty]

the REST API is planned for next release (17.06.0-beta7) I believe that @jakud or @lopiola have more information in that regard.