Re: why is authorization in a separate layer from the model?

Take a look at IDDD pages 75-79, and specifically at the refactored code on pages 78-79. It's not that it is absolutely wrong to in essence authorize the user in the model. Rather, it's that the authorization is done for free when obtaining the necessary Author instance from the CollaboratorService.

Further, it's a matter that the Author is an essential part of the Ubiquitous Language, while your Session is not. If anything, rather than pass in Session (or worse yet, SecuritySession), pass in CollaboratorService instead, and use CollaboratorService to get the Author from the Forum's own Tenant and parameter String anAuthorId.

In my sample code I show the Forum Application Service obtaining the Author via CollaboratorService. This is not wrong, because normally the API would serve as the natural client of the model. When using the Hexagonal (Ports and Adapters) architecture, requests from disparate user agent types would all be adapted to use a single API call. This is based on use case, not on user agent type. But you could pass in CollaboratorService to the Forum if you prefer.

Vaughn

--- In [email protected], Caleb Cushing <xenoterracide@...> wrote:
>
> I read DDD completely, and just got Implementing DDD and have been
> skimming for answers to my questions that came up in my failed attempt
> to implement (not all of which was technical). I've found satisfactory
> answers to most things, except a new question has come.
> 
> Implementing and other sources seem to say that Authorization belongs
> to another layer. I don't really understand why. Authentication makes
> perfect sense because how you authenticate could vary from application
> to application and environment which may share the same domain model.
> Example: On a work machine I may have a kerberos ticket which
> authenticates when I logged into the system and is then provided to
> the web server, but on an external network I may have to provide a
> username, password directly to the web application. Obviously a
> separate service, potentially with separate interfaces, makes sense.
> 
> Authorization however, IMO, and my understanding, doesn't actually
> change from environment to environment (unless you're not authorized
> to the service at all from location, or some such  in which case ...
> e.g. no access to internal service from external network). A billing
> support agent would have access to view a customers address regardless
> of desktop  fat client, or web application, or webservice. It seems to
> me that in order to avoid one of the same problems with an Anemic
> model, which is client code has to remember to do X, that putting well
> abstracted Authorization code in the model makes sense.
> 
> As a pre-note: what I'm calling "Distant AoP" which means AoP that is
> done without modifying the class, or having a direct reference to the
> object or it's constructor is not possible in my language/tools. "Near
> AoP" would be, which means I could add around modifiers to the class
> if I modified the class or intercepted it around new time or had a
> reference.
> 
> Taking the Example form " .. Implementing" on page 75 - 79. I agree
> this is a bad way to do it.
> 
> public class Forum...
> public Discussion startDisucussion ( ... )
>        ...
>       User user  = userRepository.userFor(this.tenantId(), aUsername);
> 
>        if ( !user.hasPermissionTo(Permission.Forum.StartDissuction)) {
>           throw  ...
> 
> This isn't even particularly good security code if yanked out of this object.
> 
> Instead I would think what could be written (and forgive me java is
> not my native language)
> public class Forum...
> public Discussion startDisucussion ( ... )
>        ...
> 
>        if ( ! session.checkAccess( this, 'StartDiscussion' )) {
>           throw  ... //  or perhaps even have checkAccess throw
> 
> where session was provided to the forum constructor, and is equivalent
> to the security session (or in security terms the Subject, e.g. not a
> whole http session). Under the hood this would check to see if a
> currently active role has permission to invoke start disccusion on a
> forum (again this check could be in an around modifier in the forum
> class which cowardly then refuses to run the actual StartDiscussion
> method, if that's more acceptable ). This ensure that we determine
> correct authorization whenever the model is used, and that it can't be
> forgotten. It also means that you could have an agent authorized to
> create things for the tenant. The individual needing to be authorized
> to do something is not necessarily the individual it's done for, and
> so all of the other model logic applies. To me this authorization
> check is a business rule, because under the hood it 's equating to can
> role Agent (or Tentant ) start a discussion.
> 
> Why am I wrong? where should this authorization check actually live?
> and what does that code look like? (references to DDD or Implementing
> fine)
> --
> Caleb Cushing
> 
> http://xenoterracide.com
>




------------------------------------