I am designing an Event Store implementation where I will have domain events and integration events. The integration events will write to their own stream.
I want to authorize specific services to be able to read from these integration event streams and not be able to access any of the domain event streams within once service.
I have seen users and ACLs in the documentation.
I was thinking of creating a user per service so that the user (service) can authenticate and authorize against an integration event stream. The integration event stream has an entry in the ACL where it can check whether the user can read from it or not.
Is this the correct way of authorizing a system against a stream?
My confusion comes from me thinking that there should be an option to authorize service against stream without having to authenticate or create a user but create a token for a service.
you can use groups as well.
- Indeed we only support role based access security ATM
- user/pwd as authentication mechanism in the open source version
So if I add Active Directory into the mix with OAuth2 how would the system Authenticate or Authorize against a Stream? Do you have a link on how to register services to get a Bearer Token or which concepts I need to learn to understand how this will work?
Taht’s part of the commercial offering.
instead of using the built in user/pwd you atuthenticate againts your own system.
and then it still is Role / user based ( so the ACL on the stream level is tha same )
Just to be sure I have to explain what I understand in a more detailed manner, please correct me if something is wrong in my understanding.
So Azure B2C supports registering applications to be able to Authorize against it.
Heres how I imagine getting to Authorize a specific application against a stream.
1.- I register my service (backend) in Azure B2C as an application
2.- I define a group in Event Store DB cloud
3.- I define a policy in Event Store DB cloud for that group to be able to access the integration event stream only with read rights
4.- In Azure B2C I add the group name of Event Store DB to the scopes of that application.
5.- My service subscribes to the integration event stream.
6.- When the ESDB cloud server pushes the next event from the stream to the service then it gets the scope of the bearer token and looks if the service is in the correct group to recieve events from that stream
My assumptions here are that ESDB pushes events because I’m using persistent-subscriptions.
I have a feeling that theres something wrong with my workflow.
One problem is: I think that maybe it is the service that is subscibed to the stream that constantly pings ESDB.
Anothe problem is that there is “magic” happening on step 6 where I don’t understand how ESDB will ask for an authorization bearer token and automatically understand that the scope == the group defined on the ESDB cloud webportal.
Event Store DB cloud
You mean the managed offering Event Store DB cloud ( https://console.eventstore.cloud/) ?
Hello yves, yes I mean the managed offering from ESDB cloud.
I have talked to the security expert in my company to help me with understanding your documentation.
Our main question is: Is it possible for the cloud ESDB to trust to the trusted intermediary or are we forced to use on-prem ESDB because of the localhost loop? -> The assumptions we are making are below.
ESDB supports user/pass which we don’t want.
LDAP is also supported but it does not fit into our architecture where we want to authorize and authenticate using OpenIdConnect which is a generalized standard.
Trusted intermediary:
Cons:
- You can’t use it in the cloud and need to operate this service on your own.
- Can not be deployed to the cloud because ESDB need to trust a custom header.
- Performance is affected because trusted intermediary needs to be scaled.
- SCS is registered as an application on AD B2C
- SCS authorizes against AD B2C through OpenIdConnect
- AD B2C issues bearer token
- SCS gets the token from AD B2C
- SCS tries to append an event on a ESDB stream
- SCS communicates with the trusted intermediary reverse proxy
- The trusted intermediary translates the bearer token into a plain text header which is sent to ESDB
- ESDB then checks the header against the policies defined fr the groups in the header
on the front of the managed cloud offering
- the users at the console level have nothing to do with DB users,it’s basically for resources & management of the projects, networks, provisioning etc.
- the DB , in the cloud offering, only have user/pwd.
pinging @alexey.zimarev for more complete answer
1 Like
bump this message to get some answers
I haven’t replied because @yves.lorphelin described it correctly. We are looking into a possibility to enable some settings to be changed, and trusted intermediary can be one of them.
One thing I can’t say for sure is how to use a trusted intermediary, which assumes you use a rev proxy, with gRPC streaming. I’ve never tried it.
We do have plans to support cloud-native authentication providers, but I can’t say when it will be done.
1 Like