3 ms·
WRT #2. Data isolation argument. it is not clear to me, why data isolation is your view, is exclusive to microservices. I have build non trival RBAC+ABAC aut
by maga_2020 9y ago
WRT #2. Data isolation argument.
it is not clear to me, why data isolation is your view, is exclusive to microservices.
I have build non trival RBAC+ABAC authorization platforms, using PDP and embedeabble PEP, and did not find that it was useful by micro services only. And I did not feel that it can only be called via 'micro service' pipeline.
In a way the Authorization is a separate service, yes, but it should be offering an embeddable PEP (policy enforcement point) that one can embed (link or call out-of-process if needed), from pretty much anywhere (monolith, or any runtime component).
Authorization decisions require very very low latency, as you are authorizing pretty much every data or function interaction.
In fact, for data interaction, authorization engines offer SQL-rewriting/filtering -- so that the actual 'enforcement' happens at the layer of database you are using, not even at the layer of the component that's accessing the data.
- klodolph 9y agoI think you may have misread my comment. I said "authentication" and you are talking about "authorization". Authentication can be very easily centralized in a separate service, authorization is a completely different beast. Authentication often involves access to high-value data such as hashed passwords, authorization does not.
- andyfleming 9y agoAuthorization and authentication are two different discussions. Protecting the data necessary for authentication is valid rationale. That same service could provide read-only data to another service in a single response that would allow for all subsequent authorization logic to be done without any additional latency. Additionally that data necessary for authorization may not be sensitive like the other data used for authentication.