I’m always collecting links to articles to read so that I have something to do after firing off a compile… and yesterday I got an interesting one.

I do agree with the authors that “…a variety of resources need to be secured, including what data a user is able to see, what modules they can load, or what screens they can access.” But it’s difficult to determine their level of commitment to this statement when you see their client-side security implementation tied at the hip to UIComponents. Man shall not live by UIComponents alone!

After looking at the source of the Flexible Chimp… I wondered if this was a draft? Ok… I need to be fair and get down to my bullets.

Principle of Least Privilege / Authority
The article spends a chunk of time and space talking about how you need to get your security bits in place to make sure that ‘things’ don’t slip through the cracks. An enterprise solution shouldn’t have to sweat initialization… get your security manager in place as soon as you can and make sure that anything requiring security is already off/inaccessible/not-visible/not-loaded/etc.

The beauty of Flex and AIR is that binding tops off a security solution by adding mechanisms that can greatly simplify UI updates as soon as permissions are established. In other words… don’t load anything more than is required to get the user to a login prompt. If there is anything that has to be loaded that has a security requirement it should appear as if authorization has failed (by default). My credo is, “Un-authorized clicks live forever… there is always time to enable.”

Parity of Client – Server Security
Hiding and showing controls on the client side is par for the course in managing feature access… I mean – if the user can’t click on the delete button then you’ve done your job to secure the solution right? Nope. Security should start with the server where each and every assumption is tested aggressively (do you unit test?) to ensure that each operation, method, servlet, whatnot follow your assertions. Why start with the server?

• UIs are difficult to test (especially with Flex and AIR) and typically have the most bugs
• If your UI is broken the server should kick you in the pants... if it doesn't you are in trouble
• Failing hard and fast when implementing a UI helps refine the user experience
• APIs don't have an interface...

Security is Relative
I haz to grin when I read, “…provides an ideal solution for fully securing enterprise Flex applications.” Put a proxy server in front of a Spring/BlazeDS solution and see what happens… does Spring see Firefox the same way it does IE? (session management is interesting)… remember that we are dealing with HTTP which is a connectionless protocol? I could go on for a while on this one but suffice it to say – security should be proportional to the value of your data. Nothing more. Nothing less. If Spring + BlazeDS is good enough… it’s good enough. If you have a high profile solution that needs ninjas watching it 24/7 you will probably be talking to RSA for a ‘fully secured solution.’

Solutions can quickly turn into snake-oil if you don’t watch your verbiage. I’m just sayin’