Is there still interest in Macaroons?

[anthon...@figure-eight.com]

I was put on the path to macaroons by some fellow architects online and I am interested in moving our internal microservices to using Macaroons. Right now we have a whole set of microservices who's only security is a Security Group on AWS that, when we start deploying to other platforms, is not going to be portable.

In the past companies I've worked with they used basic auth to secure internal services, though it's definitely not up to scratch when trying to integrate with external APIs and manage permissions.

For the last 2 months I've been researching and testing out implementations of security for macaroons:

• Boulangerie for our Rails apps
  
• nitram509 for our Spring Boot apps
  

I have even started a spring security extension for Spring and Spring boot applications. My only concern is why the market is so small and the people deaf about macaroons?

My research so far has led me to being able to take basic macaroons and authenticate a user and more recently I've delved into using caveats and trying to come up with a model that says "Id: user123" has the ability to "access = READ, function = USERS" or something along those lines. But more so working out how to keep a chaining model from Service A to Service B to Service C simple. It kind of feels like macaroons are used for specificity rather than general roles making the use cases you need to cater for more complicated models.

I will admit trying to retrofit a security model such as macaroons into a framework such as Spring Security has it's challenges, but it's more the security model I've been trying to create which has been more of a challenge.

So far my questions are:

• Are macaroons still worth pursuing?
  
• Has anyone here that has implemented a security model with macaroons ended up regretting it?
• Gone back and had to start from scratch?
  
• Should I continue full steam ahead or cut my losses and fallback to something else?

Anthony

[Justin Cormack]

Hi,

On 6 July 2018 at 21:33, anthony.ikeda via Macaroons

<maca...@googlegroups.com> wrote:
> I was put on the path to macaroons by some fellow architects online and I am
> interested in moving our internal microservices to using Macaroons. Right
> now we have a whole set of microservices who's only security is a Security
> Group on AWS that, when we start deploying to other platforms, is not going
> to be portable.

Absolutely, cloud provider IAM is their biggest lock in.

> In the past companies I've worked with they used basic auth to secure
> internal services, though it's definitely not up to scratch when trying to
> integrate with external APIs and manage permissions.
>
> For the last 2 months I've been researching and testing out implementations
> of security for macaroons:
>
> Boulangerie for our Rails apps
> nitram509 for our Spring Boot apps
>
>
> I have even started a spring security extension for Spring and Spring boot
> applications. My only concern is why the market is so small and the people
> deaf about macaroons?

Partly I think there are few examples for people to look at. There are people
advocating them, eg most recently
https://latacora.singles/2018/06/12/a-childs-garden.html
There are not integrations with fully worked examples into common frameworks.

> My research so far has led me to being able to take basic macaroons and
> authenticate a user and more recently I've delved into using caveats and
> trying to come up with a model that says "Id: user123" has the ability to
> "access = READ, function = USERS" or something along those lines. But more
> so working out how to keep a chaining model from Service A to Service B to
> Service C simple. It kind of feels like macaroons are used for specificity
> rather than general roles making the use cases you need to cater for more
> complicated models.

Hmm, that seems like trying to retrofit an RBAC model into macaroons. I
think it helps to start from a more capability based approach. If you start
with an RBAC model you will end up with something that looks like an RBAC
model, ie like AWS. I don't think this will map nicely to caveats.

> I will admit trying to retrofit a security model such as macaroons into a
> framework such as Spring Security has it's challenges, but it's more the
> security model I've been trying to create which has been more of a
> challenge.
>
> So far my questions are:
>
> Are macaroons still worth pursuing?
> Has anyone here that has implemented a security model with macaroons ended
> up regretting it?
> Gone back and had to start from scratch?
> Should I continue full steam ahead or cut my losses and fallback to
> something else?

I think it is quite a lot of work to build what you want; I have been
thinking about
design of a similar layer for capability based auth over cloud
services, there are
complexities in working around the existing IAM system so you don't end up with
two systems. I do think this is worthwhile but it may need to be a standalone
project.

Justin

[Evan Cordell]

You're asking a group of macaroon enthusiasts if macaroons are worth using :) The answers here will likely contains some bias.

Macaroons are definitely worth using for certain use-cases. There are now plenty of great libraries for building things with macaroons, which makes it easy to build bespoke authorization solutions for integrating all kinds of services under your control. They're easy to write, verify, understand, and audit, which makes them great to work with.

That said, it's harder to justify them for as many cases as they could be good for, IMO, simply because of the current state of the ecosystem. There's not much in the way of standards (especially in terms of caveats) and there are no large services providing macaroon integrations points (discharges). There are lots of cases where macaroons may make things harder for you simply because you'll need to write more infrastructure yourself instead of taking a solution off the shelf. And the current libraries don't yet fully deliver on some of the more interesting macaroon features (structural caveats, publicly-verifiable constructions, etc)

As for the details you gave for your particular implementation, I think macaroons work better when used more like object capabilities than like rbac systems. I.e., associate a macaroon with the resources in question, and then add caveats that confine how those resources can be accessed (rather than building a macaroon around a user identity).

[Jonah Benton]

On Mon, Jul 9, 2018 at 9:27 AM, Evan Cordell <cordel...@gmail.com> wrote:

You're asking a group of macaroon enthusiasts if macaroons are worth using :) The answers here will likely contains some bias.

Macaroons are definitely worth using for certain use-cases. There are now plenty of great libraries for building things with macaroons, which makes it easy to build bespoke authorization solutions for integrating all kinds of services under your control. They're easy to write, verify, understand, and audit, which makes them great to work with.

That said, it's harder to justify them for as many cases as they could be good for, IMO, simply because of the current state of the ecosystem. There's not much in the way of standards (especially in terms of caveats) and there are no large services providing macaroon integrations points (discharges). There are lots of cases where macaroons may make things harder for you simply because you'll need to write more infrastructure yourself instead of taking a solution off the shelf. And the current libraries don't yet fully deliver on some of the more interesting macaroon features (structural caveats, publicly-verifiable constructions, etc)

As for the details you gave for your particular implementation, I think macaroons work better when used more like object capabilities than like rbac systems. I.e., associate a macaroon with the resources in question, and then add caveats that confine how those resources can be accessed (rather than building a macaroon around a user identity).

This ^^ is helpful perspective. When looking earlier I had come to the conclusion that Macaroons and JWTs are complementary. Macaroons can solve for cases where the auth layer knows ahead of time what caveats need to be checked, where you can mint a specific authorization for a specific resource. But if what you need is, e.g., generic microservice authorization, where a bearer token needs to be dynamically interrogated, JWTs, as problematic as they otherwise are, are a more natural fit. 

That said, it also seemed like Macaroons + a policy language could potentially meet both capability-based and constraint-based needs. 

 

On Friday, July 6, 2018 at 4:33:03 PM UTC-4, anthon...@figure-eight.com wrote:

I was put on the path to macaroons by some fellow architects online and I am interested in moving our internal microservices to using Macaroons. Right now we have a whole set of microservices who's only security is a Security Group on AWS that, when we start deploying to other platforms, is not going to be portable.

In the past companies I've worked with they used basic auth to secure internal services, though it's definitely not up to scratch when trying to integrate with external APIs and manage permissions.

For the last 2 months I've been researching and testing out implementations of security for macaroons:

• Boulangerie for our Rails apps
  
• nitram509 for our Spring Boot apps
  

I have even started a spring security extension for Spring and Spring boot applications. My only concern is why the market is so small and the people deaf about macaroons?

My research so far has led me to being able to take basic macaroons and authenticate a user and more recently I've delved into using caveats and trying to come up with a model that says "Id: user123" has the ability to "access = READ, function = USERS" or something along those lines. But more so working out how to keep a chaining model from Service A to Service B to Service C simple. It kind of feels like macaroons are used for specificity rather than general roles making the use cases you need to cater for more complicated models.

I will admit trying to retrofit a security model such as macaroons into a framework such as Spring Security has it's challenges, but it's more the security model I've been trying to create which has been more of a challenge.

So far my questions are:

• Are macaroons still worth pursuing?
  
• Has anyone here that has implemented a security model with macaroons ended up regretting it?
• Gone back and had to start from scratch?
  
• Should I continue full steam ahead or cut my losses and fallback to something else?

Anthony

--
You received this message because you are subscribed to the Google Groups "Macaroons" group.
To unsubscribe from this group and stop receiving emails from it, send an email to macaroons+unsubscribe@googlegroups.com.
To post to this group, send email to maca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macaroons/bc21369c-a4a8-490b-ab99-c21d9d510679%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[anthon...@figure-eight.com]

Thanks to all who have replied so far, it's good to see there is still enthusiasm in this space.

Justin Cormack: 

> I have even started a spring security extension for Spring and Spring boot 
> applications. My only concern is why the market is so small and the people 
> deaf about macaroons? 

Partly I think there are few examples for people to look at. There are people 
advocating them, eg most recently 
https://latacora.singles/2018/06/12/a-childs-garden.html 
There are not integrations with fully worked examples into common frameworks. 

Yeah the lack of examples or some of the examples out there aren't really giving me the feel for the macaroons right now. After reading that article (great find by the way) the concepts of the first party and third party caveats are starting to make sense now. Also the fact that there should be a clear distinction between Client-Server Auth and Server-to-Server Auth, using peoples names as the services isn't helping making that clear though :)

> My research so far has led me to being able to take basic macaroons and 
> authenticate a user and more recently I've delved into using caveats and 
> trying to come up with a model that says "Id: user123" has the ability to 
> "access = READ, function = USERS" or something along those lines. But more 
> so working out how to keep a chaining model from Service A to Service B to 
> Service C simple. It kind of feels like macaroons are used for specificity 
> rather than general roles making the use cases you need to cater for more 
> complicated models. 

Hmm, that seems like trying to retrofit an RBAC model into macaroons. I 
think it helps to start from a more capability based approach. If you start 
with an RBAC model you will end up with something that looks like an RBAC 
model, ie like AWS. I don't think this will map nicely to caveats. 

Yeah I'm starting to see this now, it's taking me back to the days when I designed my first Cassandra schema and tried to apply relational concepts to it. As I mentioned a lot of the current frameworks for microservice security still follow the RBAC model which is making it tough to work around; I think the Spring Security implementation of JWT is still an RBAC technique even if you can make it stateless. It also starts to bring out how poorly some of the existing auth methods are implemented down to lack of understanding the security needs and just plain old ignorance.

Evan Cordell:

You're asking a group of macaroon enthusiasts if macaroons are worth using :) The answers here will likely contains some bias.

Totally understand and I'm sure most here have gone through what I'm going through already :)

Macaroons are definitely worth using for certain use-cases. There are now plenty of great libraries for building things with macaroons, which makes it easy to build bespoke authorization solutions for integrating all kinds of services under your control. They're easy to write, verify, understand, and audit, which makes them great to work with.

Thats good to hear as once I get a working POC to demo I need to influence the engineers on this direction. Though, as I mentioned earlier in this post, it's the muscle memory of the RBAC systems that I need to break away from the though of auth as well as the fact we are looking for a Service-to-Service solution first.

As for the details you gave for your particular implementation, I think macaroons work better when used more like object capabilities than like rbac systems. I.e., associate a macaroon with the resources in question, and then add caveats that confine how those resources can be accessed (rather than building a macaroon around a user identity).

Yup this has made things much clearer. I'm going to try and diagram an example auth flow through different services and see if I can materialise this a bit better.

Jonah Benton:

As for the details you gave for your particular implementation, I think macaroons work better when used more like object capabilities than like rbac systems. I.e., associate a macaroon with the resources in question, and then add caveats that confine how those resources can be accessed (rather than building a macaroon around a user identity).

This ^^ is helpful perspective. When looking earlier I had come to the conclusion that Macaroons and JWTs are complementary. Macaroons can solve for cases where the auth layer knows ahead of time what caveats need to be checked, where you can mint a specific authorization for a specific resource. But if what you need is, e.g., generic microservice authorization, where a bearer token needs to be dynamically interrogated, JWTs, as problematic as they otherwise are, are a more natural fit. 
That said, it also seemed like Macaroons + a policy language could potentially meet both capability-based and constraint-based needs. 

Absolutely agree here. I do plan to maintain JWTs for our public APIs and somewhat map those to the internal system. We will also have 1 particular set of APIs to allow an external deployment of the platform to communicate with the Cloud version where I could experiment more with public macaroons.

[Anthony Marquez]

I am also someone who is far from an expert in the space, but am actively trying to increase my knowledge to become a more intelligent adovocate for the technology. I also want throw out my appreciation towards the individuals in this thread who have provided their input and feedback to this thread.

One thing that I have stumbled upon that will likely help you with your implementation of macaroons into your system is the Vanadium Project (https://vanadium.github.io/). To quickly summarize it was led by some Googlers to provide a framework for created distributed applications. It was handling many portions of what that tech stack that would be required for a generic solution, a lot of which were custom protocols. Although the project has somewhat died, if you search through their code base, they are heavily influenced Macaroons (makes sense with it being a Google internal project). When you read some of their documentation, that is when things get real interesting. You can see how a caveat based authorization system can be well architected, which might help you see things from a non-RBAC based perspective. Specifically, look at these documents after you ramp up your general understanding:

https://vanadium.github.io/concepts/security.html

https://vanadium.github.io/designdocs/identity-service.html

It has helped me a lot. And I love how academic they were in their design and architecture. It's the sort of thing that makes me geek out.