Authorization Layer

[toeb]

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 call securityService.IsAuthorizedFor(cmd) . it throws a security exception if not. The first implementation just lets it pass through (dummy implementation)

Discuss!

[matthiaszoellner]

So we would basically have a command based authorization mechanism?

Lets think about it for a moment.

• Will all kind of authorized interaction (modify and view) be command based? It would be bothersome if we want to retrieve some authorized view data without a command later.
• Could there be a case where we want a single command to be authorized in some case and not in another? Like saying, someone is allowed to view accounts and update his account details, but nothing else.

Please don't misunderstand - the concept looks good as far as our current plans go.

[toeb]

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.

[matthiaszoellner]

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.

[toeb]

Ah I think I see your point. You are right maybe the need will arise for an accounting security layer .

[toeb]

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.

[matthiaszoellner]

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.