Answering a question from the community:
How do you handle security concern of sending aggregate id to the web client? What'd you do to ensure I can't, from the browser or another client, manually send aggregate id that belongs to another client to either get some data about it or send some commands to mess things up?
Each specific system scenario would lead to the specific design. If our specific scenario is:
- business logic is hosted on Application Server (e.g. hosted in Lokad.CQRS) which we control trust;
- client UI is hosted on Web server UI which we control and trust; Web server accesses application server (by sending commands and polling views) and renders HTML to user's browser.
Then the solution to the security concerns problem is:
- We don't trust client browser anything (except from keeping unique token)
- we trust Web server UI to authenticate user (ensuring that he is who he claims to be). In this web App we will ensure that client sends only commands to the aggregates he is allowed to access (while checking commands as well).
- In app service we don't do any deep security checks and just carry out the commands.
This scenario works well in simple situations where we have an app server and a few Web UI servers (alternatively with REST API servers), managed by the same team and hosted in the same controlled environment.
If we have a different environment (e.g. application server can't trust web server), then a different separation of responsibilities might be needed. For example, we might need to perform authentication within the methods of Application service (checking that user is who he claims to be), while pushing authorisation down to method calls on an aggregate (checking that user can do what he attempts to do).
In this scenario, authorisation might be encapsulated within an instance of domain service, passed down by application service to a method on aggregate. This service would have access to permission maps (or any other way of representing role/permission information), aggregate would call it's methods to find out if the specific user can perform requested actions on the requested resources.
Naturally, in this case, Web UI must still ensure that we don't send illegal commands to the server. The difference from the first scenario is - we don't trust the web server to be diligent.
These and other specifics of project environment, team organisation and trust can have a great impact on development process and product design.