Chapter 11. Security
Security is one of those aspects of development that often gets relegated to the end of the programming process. It seems like customers expect security features can be bolted on to an application. What makes things worse is you can implement security in many ways. When it comes to building security into an application, determine the requirements before you start coding. Additionally, it can be tempting to let technology drive requirements. Some technologies are flexible and let you get away with this, but when it comes to security, this is not the case. Choosing one security approach or technology over another without understanding what the user wants and needs can leave you scrambling at the end of the development cycle. You don’t want to be recoding your entire security layer before your application goes into production.
Security features center around two basic concepts: authentication and authorization. Users authenticate to the system to prove they are who they say they are. Authorization allows or disallows access to certain application features. Authentication requirements are usually specific and concrete:
Anybody can access the welcome page of the application. But if a users attempt to access any other page they will have to log in with a username and password.
Authorization needs tend to be broad and vague. In many cases, authorization rules can be complex, particularly if the authorization requirements are based on hierarchical or matrix-style ...