Macaroons for the client, initial plan

[Gustavo Niemeyer]

CCing the devel list for awareness and feedback.

Everyone, this is about the in-progress move from oauth-based
authentication to macaroons.

On Tue, Apr 5, 2016 at 12:56 PM, Matias Bordese <
matias.bordese at canonical.com> wrote:
>
> I wanted to share what my initial plan would be for the macaroons auth
> story:
>
>     (1) update store auth (store/auth) to handle macaroons (get root, get
> discharge, refresh, etc)
>             Q: where/how would it be a good place/way to store the
> macaroons?
>             (sth similar to what has been done for oauth tokens? ie. json
> data in home dir?)
>

Inside the State (overlord.State()). See overlord/* for ideas and usage
patterns, please reach out online for more insights.

    (2) add login api method (daemon/api)
>             Q: should this import directly from store/auth? should
> something be added to snappy/?
>             (add lock/unlock state + track login)
>

Seems fine to import directly. FYI, snappy/ used to be a huge catch-all
package. Nowadays it's much better already, but we want to kill it
altogether.

    (3) switch to macaroons:
>             - in login command (cmd/snappy/cmd_login), using API method
> above
>

The snappy command is dying completely, hopefully this week still. Let's
please kill the cmd_login there and replace it by something under
cmd/snap/, which is the modern CLI using the client package that talks
through the API.


>             - in existent store interactions (store/snap_remote_repo),
> setting macaroons auth expected header
>

+1

    (4) remove unused oauth code
>

+1. I wouldn't mind doing a first pass that removes login and oauth
altogether before introducing the macaroon-based implementation, if that
makes your life easier.

    (5) add macaroons refresh support
>         (will probably require an extra api method, and updates to store
> interactions to handle the refresh behind the scenes)
>

This one may require more conversation. Let's get back to it later once we
have more in place.

If this makes sense, I'll be following the given order and work on an MP
> for each item.
>

Some of these items seem like large chunks of work. I'd encourage breaking
the pull requests further into smaller items at sensible break points.
It'll make our lives easier, and your progress more engaging.

Let me know if you think we should discuss any bits, atm my main questions
> are the ones labeled with Q: above. As soon as I have some initial code
> that you can take a look at, I'll ping back (who should I mainly ping for
> this?).
>

Please feel free to ping me directly in some channel. If I'm not around,
Samuele and Michael have good context for the pieces being touched.


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160405/b958441b/attachment.html>