There. I’ve said it.
Time for developers to stop coding security into their applications and focus more on business functionality of the applications they work on.
Think about it. One of the first things a developer wrestles with is how to control users within their application. Day one, they usually build a login screen. Now where do I put the userID’s? How do I secure that? And what can this user do? What security model do I follow? For this sensitive routine, how to we control who can and who cannot get access?
My personal experience estimation is 25% – 30% of all development efforts are spent rebuilding security and identity. But as programs become more complex, more and more complexity must be built into the system. And as we all know, complexity is the Achilles Heel for security. Don’t even get me started with security and identity in cloud computing.
Instead, security should be thought of as a service. Instead of the programmer trying to learn and then implement security in their programs, they should rely on callable services to provide AuthN and AuthZ decisions. Instead of building login screens, a user identity repository, user administration screens, and provisioning sub-systems, the coder should just in calls to a security subsystem and rely on the decisions to be made for them. Drag and drop in their IDE.
We already have some of this today, but we need to adopt it at a faster pace. At the macro security level, access management and federation tools can protect an application and authenticate a user. The programmer does not have to care how the user is authenticated, only that they are authenticated by the powers that be. The user may have only supplied a user ID and password, used a challenge token, or a retina scan. The programmer does not care. It just calls the security service and asks is this user authenticated to use this application. Yes or no?
Fine grain entitlements are another matter. These too should be handled via a security service. Instead of writing convoluted security logic (lets see, if the user has this role and this entitlement, then let them do this, etc.), they should just insert a policy enforcement point (PEP). This is a call out to the security service at the start of the subsystem logic. Can the user do what they are about to try and do? The programmer does not have to worry about why the user is approved, just that they are approved.
Policy entitlement servers, which can support this PEP model, are available, but not enough applications are built using this decentralized security approach. As an enterprise continues to grow in security maturity, the benefit of this approach becomes apparent. Security policies become centralized across applications and can be managed with role based approaches. Gone are the days when security is baked into a system and the original team leaves, leaving the organization with questions on how the security in the application works or how to change it to meet new policies.
Brittle security code is a thing of the past when all a programmer has to do is treat security as a service. Does the user have a valid session to use this application? Yes/No. Drag authorization point in the IDE into the program’s workflow and not worry how the user is validated. Can the user run this report? Yes/No. Cut a check and pay a vendor? Yes/No. Much simpler when this is removed from the code and PEP’s inserted.
New regulation passed by who know who? Change in the security policy of the company? Much easier to manage with all user information and security policies in a central location. Change the policy and the applications behavior is changed without recoding and testing (well, you want to test the policy changes in UAT first, just to be safe).
Instead of 25% of the development effort spent on security issues, less than 5% of a programmer’s time is dedicated to it. Allowing them more time to focus on the functionality of the program.
So, I say, its time to get programmers out of the security business.
