why is authorization in a separate layer from the model?

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


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