He gives a good example of when an entitlements server is vital:
Suppose a homegrown portal application must present a sensitive piece of customer information such as a Social Security Number (SSN) when a service representative views a customer's profile. It is determined that in order to ensure compliance with various privacy regulations, only directors and senior managers may be able to view a customer's SSN. A decision has to be dynamically made whenever the application must show an SSN as to whether the current user may view the actual data or some default value (e.g., "XXX-XX-XXXX"). The decision must take into account the user's job title. A dozen parts of the application that can display a customer's SSN mean a dozen places for this business logic to be applied.He then goes on to explain how an Entitlements Server works in the framework of RBAC (Role-Based Access Control) and the PEP/PDP/PIP model. Gateways like the Vordel Gateway are often deployed as the PEP part of this model, and I've written recently about the benefits of integration between the PEP and the Entitlements Server.
Now assume that the policy needs to be changed after the application has been in production for some time. The business has determined that senior managers in California may not view an SSN. This is an exceptional situation that requires another piece of information to be considered as part of the entitlement decision. But what if we take the example even further? Suppose that only directors above a certain salary grade can view SSNs. Now the entitlement logic has been split into multiple decisions based on runtime attributes. So the business logic must be adapted.
You can see that authorization or entitlement policies evolve very differently from application requirements. Having the entitlement logic "hard wired" into the business logic means changing code each time there is a policy change.