The other day, a colleague of mine and I discussed our test environment. We concluded that neither
of us had used it for a while and were hence uncertain of its state. Then, I came to think of Schrödinger’s cat, the thought experiment introduced by physicist Erwin Schrödinger in which a cat is placed in a sealed box together with a container of poison and a radioactive substance. A radioactive decay would make the poison escape from the container and kill the cat. However, exactly when the decay will occur is not predicable by quantum physics, only a probability of the occurence may be given. So, given that the state of the cat, dead or alive, cannot be observed without opening the box, its state is uncertain.
According to quantum mechanics, an unobserved nucleus is said to be in a superpositioned state,
both decayed and undecayed. Only when it is observed it seizes to be superpositioned.
Now, it is quite funny to make an analogy to this regarding software development. Unless you test
(observe) your system, it is in a superpositioned state: it both works and doesn’t work. The only
way to make it work, is to test it.
Using this analogy we will arrive at the agile software development mantra of test early, test often.
For instance, using continuous integration with unit testing and automatic acceptance testing, your
system will be in a well-defined state at (almost) all times.
I am currently working on deploying eTrust SAML Affiliate Agent (Computer Associates) for a customer , and found myself totally baffled by its behaviour. In the solution in question,
we are running a web server in front of our application server. The SAML Affiliate Agent runs as a plugin on the web server. When users are authenticated by SiteMinder via the Affiliate Agent, the Affiliate Agent will insert user identity into the HTTP header that is forwarded to the application server. On the application server, we use this header to assert the user’s identity.
The basic idea with the concept of transferring user identity in the HTTP request header, is that trust is established between the Affiliate Agent and the application. In other words, the application trusts, without proof, that the header information it receives is correct. In so doing, it trusts that the Affiliate Agent handles this correctly. (This is sometimes referred to as perimeter authentication). So far, so good.
It turns out, though, that if the Affiliate Agent is configured not to enforce authentication (thereby allowing anonymous users to access resources in the application), it allows identity information to pass through from the user agent to the application! This means that any rogue client can impersonate any user by inserting a user name into the HTTP request as the application server will assume that the user was authenticated by the Affiliate Agent! The configuration is completely insecure, I would say wide open. What the Affiliate Agent should do, but which it doesn’t, is to check for incoming headers in the request, and act on it. The best thing to do, is to log the event and deny access to the application.
Be careful out there, kids.