Authentication

[Benjamin Lerman]

 Hi team,

 Following this CL: https://codereview.chromium.org/1154223003/, it seems we need a consensus on how to do authentication in mojo.

 Mainly, I started with the assumption that for an application to get a authentication token, the user should be asked and be given the identity of the app so he can device whether to give the token or not (this follows the android model, as well as the web model, where the first time a token is requested, the user is presented with a page giving him the identity of the app and asking whether to grant permission or not).

 Adam seems to think that this is not necessary and that we should grant authentication transparently.

 WDYT?

--

        Benjamin

[Viet-Trung Luu]

From the discussion in that CL:

On 2015/05/28 15:47:10, abarth wrote:
> On 2015/05/28 at 15:23:01, blundell wrote:
> > 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.

Adam, what exactly did you have in mind here?

To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

[Adam Barth]

On Thu, May 28, 2015 at 1:04 PM Viet-Trung Luu <viettr...@chromium.org> wrote:

From the discussion in that CL:

On 2015/05/28 15:47:10, abarth wrote:
> On 2015/05/28 at 15:23:01, blundell wrote:
> > 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.

Adam, what exactly did you have in mind here?

I had in mind something more like the way a VPN works.  You configure your VPN credentials using some system-provided UI and then all the applications on your device get access to all the network resources inside the VPN.

Adam

[Benjamin Lerman]

On Thu, May 28, 2015 at 10:15 PM, Adam Barth <aba...@chromium.org> wrote:

On Thu, May 28, 2015 at 1:04 PM Viet-Trung Luu <viettr...@chromium.org> wrote:

From the discussion in that CL:

On 2015/05/28 15:47:10, abarth wrote:
> On 2015/05/28 at 15:23:01, blundell wrote:
> > 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.

Adam, what exactly did you have in mind here?

I had in mind something more like the way a VPN works.  You configure your VPN credentials using some system-provided UI and then all the applications on your device get access to all the network resources inside the VPN.

 Except that a VPN connects you to a given place that you know beforehand. If we do what you suggest, then as soon as the network service has authentication, any app in the mojo shell (which we cannot trust, as the model is the web model) will be able to do authenticated request to any host and so send an OAuth token to whoever it wants without any control from the user.

 

Adam

On Thu, May 28, 2015 at 12:51 PM, 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 Hi team,

 Following this CL: https://codereview.chromium.org/1154223003/, it seems we need a consensus on how to do authentication in mojo.

 Mainly, I started with the assumption that for an application to get a authentication token, the user should be asked and be given the identity of the app so he can device whether to give the token or not (this follows the android model, as well as the web model, where the first time a token is requested, the user is presented with a page giving him the identity of the app and asking whether to grant permission or not).

 Adam seems to think that this is not necessary and that we should grant authentication transparently.

 WDYT?

--

        Benjamin

To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

--

        Benjamin

[Viet-Trung Luu]

On Thu, May 28, 2015 at 1:15 PM, Adam Barth <aba...@chromium.org> wrote:

On Thu, May 28, 2015 at 1:04 PM Viet-Trung Luu <viettr...@chromium.org> wrote:

From the discussion in that CL:

On 2015/05/28 15:47:10, abarth wrote:
> On 2015/05/28 at 15:23:01, blundell wrote:
> > 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.

Adam, what exactly did you have in mind here?

I had in mind something more like the way a VPN works.  You configure your VPN credentials using some system-provided UI and then all the applications on your device get access to all the network resources inside the VPN.

Do you imagine there being more fine-grained control, e.g., giving Google credentials only to apps from google.com and Facebook credentials only to apps from facebook.com?

[Adam Barth]

On Thu, May 28, 2015 at 1:19 PM Benjamin Lerman <q...@google.com> wrote:

On Thu, May 28, 2015 at 10:15 PM, Adam Barth <aba...@chromium.org> wrote:

On Thu, May 28, 2015 at 1:04 PM Viet-Trung Luu <viettr...@chromium.org> wrote:

From the discussion in that CL:

On 2015/05/28 15:47:10, abarth wrote:
> On 2015/05/28 at 15:23:01, blundell wrote:
> > 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.

Adam, what exactly did you have in mind here?

I had in mind something more like the way a VPN works.  You configure your VPN credentials using some system-provided UI and then all the applications on your device get access to all the network resources inside the VPN.

Except that a VPN connects you to a given place that you know beforehand. If we do what you suggest, then as soon as the network service has authentication, any app in the mojo shell (which we cannot trust, as the model is the web model) will be able to do authenticated request to any host and so send an OAuth token to whoever it wants without any control from the user.

Currently any Mojo app can execute arbitrary code on your machine.  I agree that we need a security model for Mojo, but currently we don't have one.

On Thu, May 28, 2015 at 1:20 PM Viet-Trung Luu <viettr...@chromium.org> wrote:

Do you imagine there being more fine-grained control, e.g., giving Google credentials only to apps from google.com and Facebook credentials only to apps from facebook.com?

Maybe we have a different ideas of what problem we're trying to solve here.  Is there a design doc somewhere that explains what problem we're trying to solve with this feature?

Adam

[Viet-Trung Luu]

On Thu, May 28, 2015 at 1:45 PM, Adam Barth <aba...@chromium.org> wrote:

On Thu, May 28, 2015 at 1:19 PM Benjamin Lerman <q...@google.com> wrote:

On Thu, May 28, 2015 at 10:15 PM, Adam Barth <aba...@chromium.org> wrote:

On Thu, May 28, 2015 at 1:04 PM Viet-Trung Luu <viettr...@chromium.org> wrote:

From the discussion in that CL:

On 2015/05/28 15:47:10, abarth wrote:
> On 2015/05/28 at 15:23:01, blundell wrote:
> > 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.

Adam, what exactly did you have in mind here?

I had in mind something more like the way a VPN works.  You configure your VPN credentials using some system-provided UI and then all the applications on your device get access to all the network resources inside the VPN.

Except that a VPN connects you to a given place that you know beforehand. If we do what you suggest, then as soon as the network service has authentication, any app in the mojo shell (which we cannot trust, as the model is the web model) will be able to do authenticated request to any host and so send an OAuth token to whoever it wants without any control from the user.

Currently any Mojo app can execute arbitrary code on your machine.

Well, that won't always be the case (and/or we'll have tight sandboxing, etc.).

 

I agree that we need a security model for Mojo, but currently we don't have one.

On Thu, May 28, 2015 at 1:20 PM Viet-Trung Luu <viettr...@chromium.org> wrote:

Do you imagine there being more fine-grained control, e.g., giving Google credentials only to apps from google.com and Facebook credentials only to apps from facebook.com?

Maybe we have a different ideas of what problem we're trying to solve here.  Is there a design doc somewhere that explains what problem we're trying to solve with this feature?

That's indeed a good question (for blundell & qsr): What's the use-case for the AuthenticatingURLLoader, etc.?

 

Adam

[Colin Blundell]

Hi,

Here's a design doc that explains the problems that we're looking to solve, the security model that we're currently assuming, and the different approaches that we've considered based on that security model.

(FYI, I'll be OOO Monday-Tuesday).

Thanks,

Colin

[Adam Barth]

Based on the problem statement in that document, it sounds like a VPN-like approach would work fine.  We'd have a different security model, of course, but I don't see anything in the problem statement that requires that we use that particular security model.

Adam

[Benjamin Lerman]

 I don't understand what you mean with a vpn based approach. In the statement we want to let the user know exactly when it is giving a token and to whom. How do you envision doing this without the application that needs authentication stating his identity?

 Can you write a design doc describing your approach?

--

        Benjamin

[Adam Barth]

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

 

In the statement we want to let the user know exactly when it is giving a token and to whom.

Nothing in the problem statement in the document you linked has that requirement.  That requirement arises in the security model you've invented to as part of a proposed solution to the problem statement.  I'm suggesting we use a different solution with a different security model.

 

How do you envision doing this without the application that needs authentication stating his identity?

I'm suggesting we drop this additional requirement that you've added that isn't needed to solve the problem we need to solve.

Can you write a design doc describing your approach?

The approach I'm advocating is described in the document you linked under the heading "An Alternative Security Model that Enables Client Transparency" together with implementation approach 3 under the heading "How Do We Implement an Authenticating URLLoader?"

[Benjamin Lerman]

On Fri, May 29, 2015 at 4:38 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

 

In the statement we want to let the user know exactly when it is giving a token and to whom.

Nothing in the problem statement in the document you linked has that requirement.  That requirement arises in the security model you've invented to as part of a proposed solution to the problem statement.  I'm suggesting we use a different solution with a different security model.

 

How do you envision doing this without the application that needs authentication stating his identity?

I'm suggesting we drop this additional requirement that you've added that isn't needed to solve the problem we need to solve.

 I don't think we should implement a software that sends oauth2 token without user consent, and I will need confirmation from security and privacy before implementing this.

--

        Benjamin

[Alexandre Zani]

On Fri, May 29, 2015 at 7:38 AM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

How would that work with the user having multiple identities it can authenticate as? (Say, authentication to Facebook vs authentication to Google) At the very least, the app would need to be able to specify which identity it wants to use.

[Adam Barth]

On Fri, May 29, 2015 at 7:43 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 4:38 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

 

In the statement we want to let the user know exactly when it is giving a token and to whom.

Nothing in the problem statement in the document you linked has that requirement.  That requirement arises in the security model you've invented to as part of a proposed solution to the problem statement.  I'm suggesting we use a different solution with a different security model.

 

How do you envision doing this without the application that needs authentication stating his identity?

I'm suggesting we drop this additional requirement that you've added that isn't needed to solve the problem we need to solve.

I don't think we should implement a software that sends oauth2 token without user consent, and I will need confirmation from security and privacy before implementing this.

We've already implemented software that executes arbitrary code from the network without any sandboxing.  If over-sharing oauth2 tokens is an implementation blocker, then we'll need to implement sandboxing before we can implement the authentication service.

IMHO, security concerns ought not block implementation because we're not shipping this system.

Adam

[Adam Barth]

On Fri, May 29, 2015 at 7:45 AM Alexandre Zani <az...@google.com> wrote:

On Fri, May 29, 2015 at 7:38 AM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

How would that work with the user having multiple identities it can authenticate as? (Say, authentication to Facebook vs authentication to Google) At the very least, the app would need to be able to specify which identity it wants to use.

I would recommend not solving that problem at this time.  Solving that problem isn't required to solve the problem described in the problem statement.

Adam

[Benjamin Lerman]

 The sandboxing part is a work in progress  that doesn't change the API of what we are constructing. Here we are designing an API that has no reason to be throwable.

 

Adam

--

        Benjamin

[Adam Barth]

Is there some reason we can't view the authentication service as work in progress?  The approach I'm suggesting has extremely little API (because it's transparent to consumers of the network service), which means it won't be thrown away.  The interceptor facility is generally useful and used for many things in Chrome.  In fact, it's so useful it's exposed to extension authors.

By contrast, the approach you're suggesting requires essentially every app to deal with the complexities of an authentication service in order to solve a problem we don't yet have.

Adam

[Benjamin Lerman]

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

--

        Benjamin

[Adam Barth]

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

Adam

[Benjamin Lerman]

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

 

Adam

On Fri, May 29, 2015 at 5:18 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:14 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 5:12 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:43 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 4:38 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

 

In the statement we want to let the user know exactly when it is giving a token and to whom.

Nothing in the problem statement in the document you linked has that requirement.  That requirement arises in the security model you've invented to as part of a proposed solution to the problem statement.  I'm suggesting we use a different solution with a different security model.

 

How do you envision doing this without the application that needs authentication stating his identity?

I'm suggesting we drop this additional requirement that you've added that isn't needed to solve the problem we need to solve.

I don't think we should implement a software that sends oauth2 token without user consent, and I will need confirmation from security and privacy before implementing this.

We've already implemented software that executes arbitrary code from the network without any sandboxing.  If over-sharing oauth2 tokens is an implementation blocker, then we'll need to implement sandboxing before we can implement the authentication service.

IMHO, security concerns ought not block implementation because we're not shipping this system.

The sandboxing part is a work in progress that doesn't change the API of what we are constructing. Here we are designing an API that has no reason to be throwable.

Is there some reason we can't view the authentication service as work in progress?  The approach I'm suggesting has extremely little API (because it's transparent to consumers of the network service), which means it won't be thrown away.  The interceptor facility is generally useful and used for many things in Chrome.  In fact, it's so useful it's exposed to extension authors.

By contrast, the approach you're suggesting requires essentially every app to deal with the complexities of an authentication service in order to solve a problem we don't yet have.

Adam

--

        Benjamin

--

        Benjamin

[Adam Barth]

On Fri, May 29, 2015 at 8:31 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

Sounds like a decision for the Mojo services TL.  Who is that?

[Viet-Trung Luu]

On Fri, May 29, 2015 at 8:53 AM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:31 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

Sounds like a decision for the Mojo services TL.  Who is that?

That would be jamesr (who's out today, I guess).

My opinion (at least according to how I understand/misunderstand the ongoing discussion):

• Having separate AuthenticatingURLLoader and URLLoader interfaces seems unfortunate, and leads to unnecessarily complicated code down the stack (since people will have to deal with both). Why wouldn't the AuthenticatingURLLoaderFactory just produce URLLoaders?
• Having an AuthenticatingURLLoaderFactory also seems somewhat unfortunate, especially since it leads to a lot of questions about how it relates to the NetworkService and things like the cookie store.
• The NetworkService interface is poorly split up. It seems to me that it really should be split up, part of which would end up in something like an "URLLoaderFactory" (+ related things, like cookies).
• Of course, if we had an "URLLoaderFactory" (but maybe that's a bad name), I doubt we'd want a parallel authenticating version.
• Then perhaps we'd end up diverging (between authenticating and not) at the factory-factory level, which seems bad (and also inflexible).

Now, I don't have a good idea about the interface for setting up interceptors, etc., but the general idea seems more flexible and less intrusive to me. In particular, my first point above still stands -- I don't think we should have divergent, parallel interfaces for loading URLs.

[Benjamin Lerman]

On Fri, May 29, 2015 at 10:25 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:53 AM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:31 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

Sounds like a decision for the Mojo services TL.  Who is that?

That would be jamesr (who's out today, I guess).

My opinion (at least according to how I understand/misunderstand the ongoing discussion):

• Having separate AuthenticatingURLLoader and URLLoader interfaces seems unfortunate, and leads to unnecessarily complicated code down the stack (since people will have to deal with both). Why wouldn't the AuthenticatingURLLoaderFactory just produce URLLoaders?
• Having an AuthenticatingURLLoaderFactory also seems somewhat unfortunate, especially since it leads to a lot of questions about how it relates to the NetworkService and things like the cookie store.
• The NetworkService interface is poorly split up. It seems to me that it really should be split up, part of which would end up in something like an "URLLoaderFactory" (+ related things, like cookies).
• Of course, if we had an "URLLoaderFactory" (but maybe that's a bad name), I doubt we'd want a parallel authenticating version.
• Then perhaps we'd end up diverging (between authenticating and not) at the factory-factory level, which seems bad (and also inflexible).

Now, I don't have a good idea about the interface for setting up interceptors, etc., but the general idea seems more flexible and less intrusive to me. In particular, my first point above still stands -- I don't think we should have divergent, parallel interfaces for loading URLs.

 Trung, I agree with all that you say. AuthenticatingURLLoaderFactory is there because we started before the network service was forked, so we couldn't easily change it. Adding interceptor will allow to use a single interface for the network service and for loading URLs. But this is not the real issue at hands. The bottom issue is that Adam wants the authentication to be completely transparent to the mojo apps. I want each app that want authentication to provide the authentication service. With Adam proposal the user won't be able to know which app is requesting token and as soon as authentication is setup, all applications will be able to use authentication indistinctively. With my proposal, getting an authenticated network service will be a little bit more complicated (3 more lines), but will allow the user to know which app is requesting authentication.

 

  

Adam

 

On Fri, May 29, 2015 at 5:18 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:14 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 5:12 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:43 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 4:38 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

 

In the statement we want to let the user know exactly when it is giving a token and to whom.

Nothing in the problem statement in the document you linked has that requirement.  That requirement arises in the security model you've invented to as part of a proposed solution to the problem statement.  I'm suggesting we use a different solution with a different security model.

 

How do you envision doing this without the application that needs authentication stating his identity?

I'm suggesting we drop this additional requirement that you've added that isn't needed to solve the problem we need to solve.

I don't think we should implement a software that sends oauth2 token without user consent, and I will need confirmation from security and privacy before implementing this.

We've already implemented software that executes arbitrary code from the network without any sandboxing.  If over-sharing oauth2 tokens is an implementation blocker, then we'll need to implement sandboxing before we can implement the authentication service.

IMHO, security concerns ought not block implementation because we're not shipping this system.

The sandboxing part is a work in progress that doesn't change the API of what we are constructing. Here we are designing an API that has no reason to be throwable.

Is there some reason we can't view the authentication service as work in progress?  The approach I'm suggesting has extremely little API (because it's transparent to consumers of the network service), which means it won't be thrown away.  The interceptor facility is generally useful and used for many things in Chrome.  In fact, it's so useful it's exposed to extension authors.

By contrast, the approach you're suggesting requires essentially every app to deal with the complexities of an authentication service in order to solve a problem we don't yet have.

Adam

--

        Benjamin

--

        Benjamin

--

        Benjamin

[Viet-Trung Luu]

On Fri, May 29, 2015 at 2:00 PM, 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 10:25 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:53 AM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:31 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

Sounds like a decision for the Mojo services TL.  Who is that?

That would be jamesr (who's out today, I guess).

My opinion (at least according to how I understand/misunderstand the ongoing discussion):

• Having separate AuthenticatingURLLoader and URLLoader interfaces seems unfortunate, and leads to unnecessarily complicated code down the stack (since people will have to deal with both). Why wouldn't the AuthenticatingURLLoaderFactory just produce URLLoaders?
• Having an AuthenticatingURLLoaderFactory also seems somewhat unfortunate, especially since it leads to a lot of questions about how it relates to the NetworkService and things like the cookie store.
• The NetworkService interface is poorly split up. It seems to me that it really should be split up, part of which would end up in something like an "URLLoaderFactory" (+ related things, like cookies).
• Of course, if we had an "URLLoaderFactory" (but maybe that's a bad name), I doubt we'd want a parallel authenticating version.
• Then perhaps we'd end up diverging (between authenticating and not) at the factory-factory level, which seems bad (and also inflexible).

Now, I don't have a good idea about the interface for setting up interceptors, etc., but the general idea seems more flexible and less intrusive to me. In particular, my first point above still stands -- I don't think we should have divergent, parallel interfaces for loading URLs.

 Trung, I agree with all that you say. AuthenticatingURLLoaderFactory is there because we started before the network service was forked, so we couldn't easily change it. Adding interceptor will allow to use a single interface for the network service and for loading URLs. But this is not the real issue at hands. The bottom issue is that Adam wants the authentication to be completely transparent to the mojo apps. I want each app that want authentication to provide the authentication service. With Adam proposal the user won't be able to know which app is requesting token and as soon as authentication is setup, all applications will be able to use authentication indistinctively. With my proposal, getting an authenticated network service will be a little bit more complicated (3 more lines), but will allow the user to know which app is requesting authentication.

Maybe I'm misunderstanding Adam, but my impression is that the idea is to view authentication as a work-in-progress: for now, just give the keys to the kingdom to everyone (but this is just a starting point).

Later, we could still, e.g.:

• Add a generic interceptor facility.
• Allow the network service to automatically configure authentication (or other interceptors) on a per-app/per-domain/whatever basis.
• Allow apps to manually configure/request authentication (or other interceptors), on a per-whatever basis (e.g., for a single connection, permanently, etc.).

To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

[Benjamin Lerman]

On Fri, May 29, 2015 at 11:12 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

On Fri, May 29, 2015 at 2:00 PM, 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 10:25 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:53 AM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:31 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

Sounds like a decision for the Mojo services TL.  Who is that?

That would be jamesr (who's out today, I guess).

My opinion (at least according to how I understand/misunderstand the ongoing discussion):

• Having separate AuthenticatingURLLoader and URLLoader interfaces seems unfortunate, and leads to unnecessarily complicated code down the stack (since people will have to deal with both). Why wouldn't the AuthenticatingURLLoaderFactory just produce URLLoaders?
• Having an AuthenticatingURLLoaderFactory also seems somewhat unfortunate, especially since it leads to a lot of questions about how it relates to the NetworkService and things like the cookie store.
• The NetworkService interface is poorly split up. It seems to me that it really should be split up, part of which would end up in something like an "URLLoaderFactory" (+ related things, like cookies).
• Of course, if we had an "URLLoaderFactory" (but maybe that's a bad name), I doubt we'd want a parallel authenticating version.
• Then perhaps we'd end up diverging (between authenticating and not) at the factory-factory level, which seems bad (and also inflexible).

Now, I don't have a good idea about the interface for setting up interceptors, etc., but the general idea seems more flexible and less intrusive to me. In particular, my first point above still stands -- I don't think we should have divergent, parallel interfaces for loading URLs.

 Trung, I agree with all that you say. AuthenticatingURLLoaderFactory is there because we started before the network service was forked, so we couldn't easily change it. Adding interceptor will allow to use a single interface for the network service and for loading URLs. But this is not the real issue at hands. The bottom issue is that Adam wants the authentication to be completely transparent to the mojo apps. I want each app that want authentication to provide the authentication service. With Adam proposal the user won't be able to know which app is requesting token and as soon as authentication is setup, all applications will be able to use authentication indistinctively. With my proposal, getting an authenticated network service will be a little bit more complicated (3 more lines), but will allow the user to know which app is requesting authentication.

Maybe I'm misunderstanding Adam, but my impression is that the idea is to view authentication as a work-in-progress: for now, just give the keys to the kingdom to everyone (but this is just a starting point).

 Which I'm not ready to implement, because it means having an app sending oauth token to anyone without user content, and I have a design that works that let the user makes the decision. And I do not think that asking application that wants authentication to setup an authentication service is bad.

 

 

Later, we could still, e.g.:

• Add a generic interceptor facility.

 We can do this now to have a more idiomatic way of configuring the network service. I have no objection for this. 

--

        Benjamin

[Ian Hickson]

On Fri, 29 May 2015, 'Benjamin Lerman' via mojo-dev wrote:
>
> Which I'm not ready to implement, because it means having an app sending
> oauth token to anyone without user content, and I have a design that
> works that let the user makes the decision. And I do not think that
> asking application that wants authentication to setup an authentication
> service is bad.

Can you elaborate on what exactly is the decision the user would be
making, how the question would be presented to the user, and how the user
is intended to make an educated decision? I've been trying to follow this
conversation but haven't quite been able to figure this part out.

Cheers,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Benjamin Lerman]

 The user would get (the first time) a message with the origin of the app that tries to do an authenticated connection and the origin of the requested URL. It can then accept or deny to send an oauth token.

--

        Benjamin

[Ian Hickson]

On Fri, 29 May 2015, Benjamin Lerman wrote:
>
> The user would get (the first time) a message with the origin of the app
> that tries to do an authenticated connection and the origin of the
> requested URL. It can then accept or deny to send an oauth token.

What is an "origin"? A certificate? scheme-host-port? scheme-IP-port? IP
protocol, IP address, and port?

[Ian Hickson]

On Sat, 30 May 2015, Benjamin Lerman wrote:

> On May 30, 2015 2:01 AM, "Ian Hickson" <i...@hixie.ch> wrote:
> > On Fri, 29 May 2015, Benjamin Lerman wrote:
> > >
> > > The user would get (the first time) a message with the origin of the
> > > app that tries to do an authenticated connection and the origin of
> > > the requested URL. It can then accept or deny to send an oauth
> > > token.
> >
> > What is an "origin"? A certificate? scheme-host-port? scheme-IP-port?
> > IP protocol, IP address, and port?
>

> Origin has the same meaning as in the context of the web, so everything
> necessary to define where is the application is coming from and where
> the connection is going to...

Origin on the Web is a bit of a failure. I mean, we make it work, by
necessity, but it's a huge pile of hacks. For example, we have to ignore
the DNS spec and pin DNS resolution to particular IP addresses beyond
their timeout time so that looking up the same DNS name twice in
succession can't result in different IP addresses being considered to have
the same origin. Similarly, to work around the restriction of schemes
being part of the origin, we force ws:// and http:// to be considered
equivalent if all else is equal for the purpose of sending cookies to
WebSocket connections. And let's not discuss data: URLs and origin
inheritance, or how people assume paths are part of the origin, or
document.domain, etc.

But ok. If by "origin" you mean "Scheme, IP-pinned host, and port", then
how would a user know the correct answer to the following questions?

Do you wish to allow this application, whose origin is:
https://www.google.com/
...to connect to the following server?
http://www.google.com/

Do you wish to allow this application, whose origin is:
http://www.irs.gov.restricted.government.access.zone/
...to connect to the following server?
https://www.wellsfargo.com/

Do you wish to allow this application, whose origin is:
http://www1.yahoo.com/
...to connect to the following server?
http://www2.yahoo.com/

Do you wish to allow this application, whose origin is:
https://www.centillion.com/
...to connect to the following server?
https://www.10e303.net/

Do you wish to allow this application, whose origin is:
https://damowmow.com/
...to connect to the following server?
https://www.damowmow.com/

Do you wish to allow this application, whose origin is:
https://www.whatwg.org/
...to connect to the following server?
https://www.whatwg.org:4443/

[Benjamin Lerman]

On Fri, May 29, 2015 at 5:53 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:31 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

Sounds like a decision for the Mojo services TL.  Who is that?

 James being away, Trung inherited the Hat. After discussing with him, here is the current plan:

 Application that want authentication will connect to mojo:authenticated_network_service instead of mojo:network_service.

 Under the hood, for this to work, on platform that have authentication, mojo:authenticated_network_service will be an alias for mojo:authentication. The authentication application will respond to request for the network service by contacting the real network service, setup an url loader interceptor able to do authentication and send the service back to the original application. Because the original application did the connection, the authentication service has the information about who is requesting tokens without the client needing to set the authentication service itself.

 

Adam

 

On Fri, May 29, 2015 at 5:18 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:14 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 5:12 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:43 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 4:38 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 7:32 AM Benjamin Lerman <q...@google.com> wrote:

I don't understand what you mean with a vpn based approach.

I mean an approach in which the user establishes some credentials that are transparently granted to every app accessing the network, just like in a desktop operating system when you connect to a VPN and |curl| on the command line can now retrieve resources inside the VPN.

 

In the statement we want to let the user know exactly when it is giving a token and to whom.

Nothing in the problem statement in the document you linked has that requirement.  That requirement arises in the security model you've invented to as part of a proposed solution to the problem statement.  I'm suggesting we use a different solution with a different security model.

 

How do you envision doing this without the application that needs authentication stating his identity?

I'm suggesting we drop this additional requirement that you've added that isn't needed to solve the problem we need to solve.

I don't think we should implement a software that sends oauth2 token without user consent, and I will need confirmation from security and privacy before implementing this.

We've already implemented software that executes arbitrary code from the network without any sandboxing.  If over-sharing oauth2 tokens is an implementation blocker, then we'll need to implement sandboxing before we can implement the authentication service.

IMHO, security concerns ought not block implementation because we're not shipping this system.

The sandboxing part is a work in progress that doesn't change the API of what we are constructing. Here we are designing an API that has no reason to be throwable.

Is there some reason we can't view the authentication service as work in progress?  The approach I'm suggesting has extremely little API (because it's transparent to consumers of the network service), which means it won't be thrown away.  The interceptor facility is generally useful and used for many things in Chrome.  In fact, it's so useful it's exposed to extension authors.

By contrast, the approach you're suggesting requires essentially every app to deal with the complexities of an authentication service in order to solve a problem we don't yet have.

Adam

--

        Benjamin

--

        Benjamin

--

        Benjamin

[Adam Barth]

On Thu, Jun 4, 2015 at 6:17 AM Benjamin Lerman <q...@google.com> wrote:

On Fri, May 29, 2015 at 5:53 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:31 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

On Fri, May 29, 2015 at 5:30 PM, Adam Barth <aba...@chromium.org> wrote:

On Fri, May 29, 2015 at 8:20 AM 'Benjamin Lerman' via mojo-dev <mojo...@chromium.org> wrote:

 1) We are going to go with interceptor.

 But 2) each app has to set the interceptor if it wants authentication., because this is a problem we have -> we want to be able to access some content that have restricted access...

We're just going in circles.  Solving the problem of being able to access restricted content doesn't require per-app authentication.  Specifically, a VPN-like approach solves that problem without requiring each app to have knowledge of the authentication service, and that's the approach I think we should use to solve the problem at hand.

 And again I don't agree, and won't implement it without security being fine with this. Now that we are clear that our views are not compatible, who do you want to escalate to?

Sounds like a decision for the Mojo services TL.  Who is that?

 James being away, Trung inherited the Hat. After discussing with him, here is the current plan:

 Application that want authentication will connect to mojo:authenticated_network_service instead of mojo:network_service.

 Under the hood, for this to work, on platform that have authentication, mojo:authenticated_network_service will be an alias for mojo:authentication. The authentication application will respond to request for the network service by contacting the real network service, setup an url loader interceptor able to do authentication and send the service back to the original application. Because the original application did the connection, the authentication service has the information about who is requesting tokens without the client needing to set the authentication service itself.

Sounds great.  Thanks!