NOT FOR COMMIT: POC of using AuthenticatingURLLoader in Sky

NOT FOR COMMIT: POC of using AuthenticatingURLLoader in Sky

This CL changes Sky to use AuthenticatingURLLoaders so that sky_viewer.mojo can access Sky apps (and their resources) that require authentication.

[blundell, 2015-05-27 16:52:02]

blundell@chromium.org changed reviewers:
+ abarth@chromium.org

[blundell, 2015-05-27 16:52:03]

Hi Adam,

I'd like to get early feedback on this POC CL:

- Overall direction
- If you're happy with the overall direction, what you'd like to see happen in
SkyShell (see the TODO in //sky/shell/ui/engine.cc).

Thanks!

[abarth-chromium, 2015-05-27 16:55:28]

Why are any changes to Sky required?  Can't we just transparently replace the
URLLoader?

[blundell, 2015-05-27 16:57:20]

On 2015/05/27 16:55:28, abarth wrote:
> Why are any changes to Sky required?  Can't we just transparently replace the
> URLLoader?

How would that work, given that Sky asks the NetworkService to create
URLLoaders?

[abarth-chromium, 2015-05-27 18:08:43]

Can we just change mojo:network_service to mojo:authenticated_network_service ?

[blundell, 2015-05-28 15:23:01]

On 2015/05/27 18:08:43, abarth wrote:
> Can we just change mojo:network_service to mojo:authenticated_network_service
?

This would be the approach of wrapping the network service that we discussed as
an alternative in
https://groups.google.com/a/chromium.org/forum/#!topic/mojo-dev/9ZaoB-Lmoqw,
right? If we're going to go that route, should we just build the authentication
facilities within the network service itself now that we have the ability to do
so?

It can't be 100% transparent to clients even if we put the authentication logic
directly in the network service due to the fact that it's the client that needs
to connect to the AuthenticationService and then supply that service to the
{AuthenticatingURLLoader, NetworkService}. The reason that it's the client's
responsibility to do that is that the AuthenticationService needs to show the
identity of the app requesting permissions to the user; if e.g. the
NetworkService made the connection to the AuthenticationService itself, then
every authentication request would look like it came from the NetworkService.
(An alternative here would be to have the AuthenticationService take in an
optional "alias" to display and use that if it trusts the app that connected to
it; however, that seems unscalable as it requires that the AuthenticationService
trust every app that could ever make a request for an authenticated resource on
behalf of another app).

However, if we go the route of putting the logic in the NetworkService, then the
changes to Sky (and any client that needs to use authentication) become much
more minimal: simply connect to the AuthenticationService after connecting to
the NetworkService and call |SetAuthenticationService| on the NetworkService
before using it.

Thoughts?

[abarth-chromium, 2015-05-28 15:47:10]

On 2015/05/28 at 15:23:01, blundell wrote:
> On 2015/05/27 18:08:43, abarth wrote:
> > Can we just change mojo:network_service to
mojo:authenticated_network_service ?
> 
> This would be the approach of wrapping the network service that we discussed
as an alternative in
https://groups.google.com/a/chromium.org/forum/#!topic/mojo-dev/9ZaoB-Lmoqw,
right? If we're going to go that route, should we just build the authentication
facilities within the network service itself now that we have the ability to do
so?

As I wrote in that thread, I'd recommend adding a generic interceptor facility
to the network service and then implementing authentication as an interceptor.

> It can't be 100% transparent to clients even if we put the authentication
logic directly in the network service due to the fact that it's the client that
needs to connect to the AuthenticationService and then supply that service to
the {AuthenticatingURLLoader, NetworkService}.

Why?  It seems like some other mojo app could configure the authentication
service with the appropriate credentials ahead of time and clients of the
network service could then just use them transparently.

> The reason that it's the client's responsibility to do that is that the
AuthenticationService needs to show the identity of the app requesting
permissions to the user;

Where does this requirement come from?

> if e.g. the NetworkService made the connection to the AuthenticationService
itself, then every authentication request would look like it came from the
NetworkService. (An alternative here would be to have the AuthenticationService
take in an optional "alias" to display and use that if it trusts the app that
connected to it; however, that seems unscalable as it requires that the
AuthenticationService trust every app that could ever make a request for an
authenticated resource on behalf of another app).

I don't understand where this requirement comes from, so it's difficult to
discuss the details.

> However, if we go the route of putting the logic in the NetworkService, then
the changes to Sky (and any client that needs to use authentication) become much
more minimal: simply connect to the AuthenticationService after connecting to
the NetworkService and call |SetAuthenticationService| on the NetworkService
before using it.

I don't think it's reasonable to require all clients who want to make
authenticated network requests to make these sorts of invasive changes.

[qsr, 2015-05-28 16:06:11]

On 2015/05/28 15:47:10, abarth wrote:
> On 2015/05/28 at 15:23:01, blundell wrote:
> > On 2015/05/27 18:08:43, abarth wrote:
> > > Can we just change mojo:network_service to
> mojo:authenticated_network_service ?
> > 
> > This would be the approach of wrapping the network service that we discussed
> as an alternative in
> https://groups.google.com/a/chromium.org/forum/#!topic/mojo-dev/9ZaoB-Lmoqw,
> right? If we're going to go that route, should we just build the
authentication
> facilities within the network service itself now that we have the ability to
do
> so?
> 
> As I wrote in that thread, I'd recommend adding a generic interceptor facility
> to the network service and then implementing authentication as an interceptor.
> 
> > It can't be 100% transparent to clients even if we put the authentication
> logic directly in the network service due to the fact that it's the client
that
> needs to connect to the AuthenticationService and then supply that service to
> the {AuthenticatingURLLoader, NetworkService}.
> 
> Why?  It seems like some other mojo app could configure the authentication
> service with the appropriate credentials ahead of time and clients of the
> network service could then just use them transparently.
> 
> > The reason that it's the client's responsibility to do that is that the
> AuthenticationService needs to show the identity of the app requesting
> permissions to the user;
> 
> Where does this requirement come from?

 It comes from the authentication service. This service needs to know who is
requesting authentication so that it can let the user take an informed decision
on whether to send credentials or not. The way this service knows reliably who
is requesting the credentials is by using the connecting url, because this is
ensured to be non spoofable by the system itself. Then the way to allow the
network service (or any other service) to request token on behalf of a given
application is to send an authentication service to the application. It means
that any application that wants to be able to do authenticated calls will indeed
need to do some work to setup this correctly.

> 
> > if e.g. the NetworkService made the connection to the AuthenticationService
> itself, then every authentication request would look like it came from the
> NetworkService. (An alternative here would be to have the
AuthenticationService
> take in an optional "alias" to display and use that if it trusts the app that
> connected to it; however, that seems unscalable as it requires that the
> AuthenticationService trust every app that could ever make a request for an
> authenticated resource on behalf of another app).
> 
> I don't understand where this requirement comes from, so it's difficult to
> discuss the details.
> 
> > However, if we go the route of putting the logic in the NetworkService, then
> the changes to Sky (and any client that needs to use authentication) become
much
> more minimal: simply connect to the AuthenticationService after connecting to
> the NetworkService and call |SetAuthenticationService| on the NetworkService
> before using it.
> 
> I don't think it's reasonable to require all clients who want to make
> authenticated network requests to make these sorts of invasive changes.

[abarth-chromium, 2015-05-28 16:37:21]

On 2015/05/28 at 16:06:11, qsr wrote:
> On 2015/05/28 15:47:10, abarth wrote:
> > Where does this requirement come from?
> 
> It comes from the authentication service. This service needs to know who is
requesting authentication so that it can let the user take an informed decision
on whether to send credentials or not.

I still don't understand where that requirement comes from.  Is that a
requirement you invented or is that a requirement that comes from someone else?

[qsr, 2015-05-28 18:46:55]

On 2015/05/28 16:37:21, abarth wrote:
> On 2015/05/28 at 16:06:11, qsr wrote:
> > On 2015/05/28 15:47:10, abarth wrote:
> > > Where does this requirement come from?
> > 
> > It comes from the authentication service. This service needs to know who is
> requesting authentication so that it can let the user take an informed
decision
> on whether to send credentials or not.
> 
> I still don't understand where that requirement comes from.  Is that a
> requirement you invented or is that a requirement that comes from someone
else?

 I "invented" mojo:authentication. And then we designed this interface with
Collin. So yes, I invented it if you want.

 The reason it is like this, is:

1) If you want to get a token, you need to let the user know who you are. For
this mojo:authentication use the identity of the app that connects to it (as
this is not spoofable).
2) Requesting token transparently in the network service is bad for the user,
because he won't know which app will get the information
3) Passing the AuthenticationService from the app to the network service allows
the network service to request token im behalf of the other app.

 How exactly do you envision the network service being able to do authenticated
request transparently?

[abarth-chromium, 2015-05-28 19:41:31]

It sounds like we disagree about what the requirements are and what costs we're
willing to pay to satisfy those requirements.  IMHO, the security model you've
invented here isn't going to work well because users don't have any context for
understanding URLs as security identifiers.  I don't think it's worth junking up
all this code to support this security model.  Instead, I think we should add
authentication transparently as I described via email.

[qsr, 2015-05-28 19:44:07]

On 2015/05/28 19:41:31, abarth wrote:
> It sounds like we disagree about what the requirements are and what costs
we're
> willing to pay to satisfy those requirements.  IMHO, the security model you've
> invented here isn't going to work well because users don't have any context
for
> understanding URLs as security identifiers.  I don't think it's worth junking
up
> all this code to support this security model.  Instead, I think we should add
> authentication transparently as I described via email.

 Then we indeed disagree and I'm not ready to send oauth2 token anywhere without
asking the user first.