ID
OM-BP-0022
Status
| Status | ||||
|---|---|---|---|---|
|
Best Practice
Centralize authorization management outside applications.
Rationale
The key drivers for this architectural design is the high cost and complexity of development and maintenance of authorization logic, and the subsequent cost and difficulty for application owners to consistently manage authorizations in numerous heterogeneous applications.
Bad Practices
Implement authorization logic within the application
Develop a centralized authorization system with a proprietary protocol
Implementation Details
Require support for OASIS XACML as part of SDLC
Quotes
Externalizing authorization from applications
Many applications today are written with authorization logic built proprietarily into the application. This logic, often driven by sustainable ACL and RBAC policy models, is often not reusable between applications. Development teams are forced to reinvent the wheel and spend measurable time maintaining business authorization rules, rather than focusing their efforts on core application development. Additionally, accurate reporting can be a time-consuming task when IT governance teams are tasked with tracking down exactly what access an entity has at any given time across several siloed applications. This becomes a nightmare in the event of a security breach. How quickly can you react and assess the scope of the breach?
By leveraging XACML, developers can remove the authorization logic from their applications. Policies are centrally managed and can be modified based on business needs at runtime without any changes to application code.
(Blain, 2011, accessed 27 Jan 2021)
Number one is the goal to remove authorization processing from applications and implement it in a shared infrastructure service.
(Gebel and Wang, 2010, p. 119)
Bibliography
Related Best Practices
N/A
See Also
| Filter by label (Content by label) | ||||||
|---|---|---|---|---|---|---|
|