Programmatic Security

Our first instinct is to build security into our applications. After all, if your applications are attacked, you're often the first ones to get called. However, as hard as it might be to accept, it is better if you don't – that is, don't encode security policies into your business logic. In many cases, encoding security functions into your application can actually make things worse. We'll illustrate why with some scenarios:

• Multiple User Registries
  Consider a case where you've written a user login function into your application. You prompt the user for their identity (user ID) and a password. You then do a lookup in a database (a user registry) and compare the password to the value stored in the database. First, there is the question of how the database itself is being protected – what is keeping another part of your application, or some other application running on your server from accessing your database; perhaps changing the password values to blanks and thus allowing any user to sign-in as anyone they want?

  However, consider further that someone introduces another application into your business that also has its own login function using a completely different user registry. Assuming there is some chance that the same users will need to use both applications at some point then this creates two problems that eventually lead to integrity issues:

  • The first is that since these are separate registries there is a high probability that each will contain a different password for the same user. This means that the user has to remember two different passwords – maybe even two different user IDs. Given the natural limitations of the human brain, eventually, people will start writing their passwords down somewhere to help them remember them. Of course, whenever you write a secret down you've increased the chances of someone else discovering that secret.

  • The other problem that occurs in this scenario is that you've doubled the number of registries that have to be administered. If you later discover that one of your users is malicious or poses some other threat that leads you to want to remove them from your system you now have two different places to go to erase their user entry – assuming, of course, that the user held something in common like the same name or address in both registries that allows you to recognize the user in both places. Often, when you're dealing with thousands, or worse, millions of users, this gets increasingly difficult to do – the same user may be identified entirely differently in different user registries, given the opportunity.

• Policy Inflexibility
  Let's say that you've encoded logic in your application that allows the Plant Store Owner and any Cashier to change a Customer order. Later you decide to increase your customer focus and so you replace all of your Cashiers with Customer Representatives and Product Specialists. You will not be able to make this change without also changing your applications. But more importantly, you will likely want to limit access to Customer orders – only allowing Customer Representatives access to the Customer order. This requires sub-setting everyone that was a Cashier, establishing their new roles, and then making sure your application has been re-coded to recognize that distinction.

• Asymmetric Protection
  Next, consider the case that you've provided security in your application, but someone installs another application that does not provide security – and, in this scenario, you both access the same back-end data. This creates an asymmetry in the protection of your data resources – in effect, a weak link. Hackers will eventually find and attack the weaker flank and use that to undermine your well-laid plans. In this case, someone using your application to illegitimately access your backend data will be denied that access. However, that same person can shift over to using the other application and will be granted access. This calls in question why you bothered with the overhead of checking – you could have just gone ahead and given them access as well and possibly have gained some legitimate customers with the additional performance and throughput you might have gained without your protection mechanisms. Before you know, if everyone adopts this same attitude in your organization, you won't have any protection mechanisms in place whatsoever.

All of these scenarios illustrate the pitfalls of embedding security directly into the business logic of your application. However, this does not mean that you should not secure your application. In fact, WebSphere makes it relatively simple to protect your system, but without requiring that you encode security into your applications. WebSphere and J2EE accomplish this through a declarative security approach. The WebSphere runtime will enforce security policies that you declare in deployment descriptors about the security needs of your application. Because they are declarative, these policies can easily be changed without having to re-code and re-build your application. Moreover, security policies can be controlled through admin user interfaces and command-line interfaces allowing you to represent aggregations of policy.

This externalization allows security administrators to examine the total set of security policies being enforced by the system and reason about the relative protection of their systems. This approach also allows you to apply security to applications even if the application developer forgets or doesn't know how to include this in their own application (it gets rid of potential asymmetry in the enforcement model).