Feature suggestion: default ACL by category

[Zach Blocker]

Been looking through the documentation for Access Control Lists. It appears one can do two things: 

1. Set default user stream ACL (global)
2. Set per-stream ACL (through UI or .NET client)

What about being able to define a per-category default ACL? 

USE CASE

Let's say I have a domain entity called "Widget", and I have a "Widget Service" which contains all the business logic and validation for creating and updating Widgets in my system.  So I'd want all services to be able to consume events from a given Widget stream (e.g. widget-48824285), I only want to grant the widgetservice user the right to write to all streams beginning with widget- (i.e. the "widget" category). 

It will be tedious to have to set the ACL rules for every individual Widget stream that the service creates, as it's created...

[James Nugent]

Hi Zach,

Right now this isn't supported - "categories" are a post-hoc mechanism imparted by the projections system and are not involved in the write path.

It is possible that we could divide up the stream namespace in a different fashion and do prefix matching on the streams, but this isn't currently on the roadmap. In many cases you'd actually want an Event Store instance per service rather than one shared among services anyway?

Thanks,

James

[Kristian Freed]

FWIW, I'd also be interested in per category ACLs, as well as any new mechanisms to further define namepaces of streams.

For our setup, we have a set of microservices each owning the creation of events for a given category, but also occasionally consuming events from each others. An event store instance (or rather, cluster) per service would be a clear overkill for us at this stage.

Cheers,

Kristian

--
You received this message because you are subscribed to the Google Groups "Event Store" group.
To unsubscribe from this group and stop receiving emails from it, send an email to event-store...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Young]

What if we gave you the ability to set privs in projections? Then you
could just arbitrarily set the permissions yourself...

--
Studying for the Turing test

[Zach Blocker]

James, I had not considered the model of one ES instance per service.  I understood that the point of Event Store was to serve two purposes:

1. Be a permanent audit record of domain events, replayable on demand.

2. Be a bus by which to inform other services of domain events. 

In other words, to be an integration layer between services instead of belonging to one service only. 

Are other folks doing event sourced microservices out there?  Are you using ES per service or one global instance as an integration layer? 

[Zach Blocker]

So, Greg, following my hypothetical use case, I would lock down my streams globally by default, but create projections on those streams and use per-projection ACL to open these specific projections for others to read.  I suppose that would work. 

[David Schmitz]

James,

regarding your 'one Event Store instance per service'... I hope I missunderstand your statement.

This conflicts with using es + cqrs for handling data distribution in microservices, or does it?

At least we are using ONE eventstore cluster for our microservice landscape (for now. Maybe down the road we will introduce multiple clusters, that depends on our domain design.)

Is this something we should avoid?

Best regards,

David