Security considerations for user authorization in applications

1. There exists a clearly defined matrix defines access permissions on resources by different user roles and processes.
2. Access to sensitive and system resources is restricted to selected roles only.
3. Authorization is based on Windows authentication
4. The system uses ACLs (in addition to other) techniques for authorization.
5. The system uses application-level, (in addition to other) techniques for authorization.
6. The system uses code access level (in addition to other) techniques for authorization. (e.g.. CAS in dot net)
7. The authorization mechanism of the application achieves from organizational changes and movements e.g.. Richard is in one role today, another tomorrow. In tomorrow's role he is less privileged than today's.
8. Identity information is passed without specific protection from one part of the application to the other, only if the sender and the receiver reside in trusted zones.
9. Identity information is passed by signing/encrypting from one part of the application to the other, if the sender and the receiver reside in non-trusted zones.
10. Authorization has been performed in the UI tier such that controls are hid/shown based on user authorization. If this is true check the following: the logic for the above is consolidated in a single section of the design documents. Where the behaviour of a control is consistent across pages, a repeater control is used.
11. The MVC pattern is used for the application.
12. If the number of roles is less and/or if the pages for each role differ to a large extent then separate UI should be created.
13. Authorization has been performed in the UI tier such that flow of UI is changed based on type of user
14. Authorization has been performed in the UI tier such that access to the entry page of the app is configured for authorized users only.
15. Authorization has been performed in the UI tier such that authorization check is carried out each time a new page is loaded.
16. Authorization has been performed at the business logic.
17. Authorization has been performed at the database level.
18. Access to database tables and other entities is being controlled using SQL Data Definition Language such as GRANT, DENY and REVOKE.
19. The database rules are being used to enforce security and authorization.
20. The architecture takes into consideration that no more data is read other than what is required to be displayed to the user.
21. All operations that perform a business process are authorized.
22. Authorization functionality is encapsulated as utility classes. (This will obviate the need for non-security minded programmers from having to learn too much about authorization)
23. Guards are present to ensure that sensitive data cannot propagate outside the data tier.
24. "If the authorization logic is simple, checks are being made in stored procedures.
25. If the authorization logic is complex, checks are being made in data access logic components and call SPs."
26. If an authorization cache is being used then it is protected by encryption (for confidentiality) and is signed (to prevent tampering)