Open toeb opened 9 years ago
So we would basically have a command based authorization mechanism?
Lets think about it for a moment.
Please don't misunderstand - the concept looks good as far as our current plans go.
point2 yes. but that would be included. the authoriyation service would check if the account belongs to the current user and let the command through if it does else rejecting it.
But this would mean, the authorization service becomes a data consumer itself (else it can't check properties at this stage). Well anyway, I think we can go with the abstract interface and dummy implementation for now. I guess our first final will be on the level of "if the user is authenticated, he is also authorized", so there shouldn't be a problem.
Ah I think I see your point. You are right maybe the need will arise for an accounting security layer .
Another Problem which must be adressed is data for which a user is to be authorized. I would suggest adding a owner, authrorized field to the Meta class which would allow group based authorization for entities.
then add add a method which only retunrs the authorized entities from a repository.
Actually I don't see the need for this level of ownership.
If we ever need a datarow-level ownership, we should put it into a separate table. Weaving authorization into the data model is not a good idea. Additionally, I'm not to motivated to deal with cases, where ownership of transactions doesn't match ownership of account - or dealing with transaction-level ownership at all. But putting ownership into Meta (and thus into transaction, partial transaction, ...) would indicate such a use.
I thought of an easy way to implement authorization logic.
Create a injected service (ISecurityService) which has a method
IsAuthorizedFor(object)
at the beginning of every command handler you callsecurityService.IsAuthorizedFor(cmd)
. it throws a security exception if not. The first implementation just lets it pass through (dummy implementation)Discuss!