...
If not all subjects in a role have the exact same access, then they need personalized privileges assigned to them. The authorization system might assign privileges directly to the subject, or in the context of an application, or in the context of a role. Either way, the subject will have privileges that are different from other subjects assigned to the same role. An example is to specify which data-sets the subject has access to when searching for data or running reports. If the authorization system supports applications with subjects which that select one role at a time to use the application, then individual privileges should be able to be assigned in context of one role. The subject will not need to have elevated privileges at all times, and thus will be less likely to accidentally perform tasks that only the elevated role can perform.
If there is no access control framework or central system, then hard-coding the privileges in the application might be the easiest way to code an application. An external privilege management system separated the privilege resources from the code, but still runs in the same application for that application. A central authorization system maintains the roles and privileges in a central location as middleware for multiple applications. External or centralized authorization gives the application run-time flexibility for changes in access control policy and authorization reporting. Centralized authorization systems can show subject's privileges across applications and can ease revocation. Certainly as auditing requirements increase, and sharing of access control policies across multiple applications, centralized authorization is required. If there is a common on-boarding workflow application, then centralized authorization can make the architecture more homogeneous.
...