Authorization refers to the ability to determine, not on the basis of the fortress making the request but on the basis of the information in the request itself, whether the request being made is allowable. As a simple example, imagine Bart the bad guy is sitting at a browser and asks that 1,000 dollars be removed from Alice's account. He knows Alice's account number but not her password. This request should be rejected. The reason for rejecting the request is not that Bart's browser is an untrusted source. Gwen, sitting in a presentation fortress, has no problem with Bart's browser. The request should be rejected because there is a problem with the data in the infogram.
Solving authorization problems generally requires deferring to the business logic. Theoretically Gwen could check the database to see if the password matched the password for Alice's account. But such checking is difficult, for different reasons, depending on what kind of a fortress Gwen is guarding.
If Gwen is guarding a presentation fortress, she has no access to the database containing account IDs and passwords. This information is obviously highly confidential, and as I have hinted at and will discuss in more detail in Chapter 10 (Internet Fortresses), we don't store confidential information in a presentation fortress.
If Gwen is guarding a business application fortress, then for performance reasons we want to minimize database access. If she has to access the database to check the password and then a business application worker has to access the same database to do the account update, we have two database accesses. If the worker does both the authorization check and the account update, we can eliminate half of the database accesses.
The bottom line is that authorization, not to be confused with authentication, is usually not a guard issue, but a business application worker issue, based on application-specific algorithms.