Simplified user and group management is the key to secure application deployment

When developing a secure solution, managing users and customizing security groups is always a challenge, and if done incorrectly, mistakes made during the initial design phase will cause years of pain and suffering for those members of the security team who will be tasking with managing and maintaining user access and resource permissions. How does one ensure that role definitions and group mappings are done correctly? It's often more of an art than a science, but more often than not, simplicity is the key to success in the world of secure application deployment.

Using pre-defined roles properly

Defining fewer Java EE roles will help simplify the task of managing security and make life easier.

For out-of-the-box Java EE applications acquired from a third party, a number of predefined user roles will exist. Never try to re-engineer the software you have just bought by trying to create new, hybrid groups in your LDAP directory that somehow combine these predefined roles. For example, the WebSphere Application Server comes equipped with the following user roles:

• Administrator
• Admin Security Manager
• Monitor
• Configurator
• Operator
• Deployer
• Auditor

Far too often, someone on the operations team concludes that life would be much easier if a new group in LDAP called the configurator-operator or the monitor-auditor would be a good idea. Simply stated, it is not. Not only does it tend to imply a misunderstanding of the various tasks that a given Java EE role has the right to perform, but it also creates a confusing level of distraction and misdirection within LDAP. Use the roles that are provided, and map existing LDAP users and LDAP groups into these roles. Hybrid grouping is a misguided attempt to simplify administration, and it always backfires in the end.

When creating your own software applications, keep the number of Java EE roles you define to a minimum. Looking back to the example of the WebSphere Application Server (WAS), you can see that there are seven roles defined. Seven roles, that is all there is for a comprehensive tool that administers an incredibly complex piece of software. If seven roles are sufficient for WAS, why is it not unusual to see simple Java EE applications, that do nothing more than take a piece of text and do a combined Tweet and Facebook update, being configured with over a dozen? Fewer Java EE roles in an application is always better and far less likely to confuse the DevOps professional who has to administer it.

Avoid fine grained access control

When architecting a secure solution, it's easy to fall into the trap of delivering fine-grained access control through the creation of special Java EE roles that have the ability to do one specific thing. This often looks like a good approach early in the design stage, but inevitably, more and more instances arise where more fine grain control is needed, resulting in a confusing set of roles where each one has nothing more than the low-level control of a single resource. When the final product gets rolled out, the abundance of user roles ends up causing great confusion for the operations team who will be tasked with managing the application. Always avoid providing fine grained access control through the creation of one-off Java EE roles.

Stick with the basics

For most Java EE applications, the only two roles you need are one for the administrator and one that defines the authenticated user. Sometimes a monitor type of role can be useful, and if the application has special regulatory constraints, an auditor role can be helpful, but anything beyond that must come with strong justifications. That's not to say you should never add more than these aforementioned groups - it's just to say that any additional groups must be justified. Not only are additional roles unnecessary, but their existence can create a great deal of confusion for the end user.

Managing the non-functional requirements of any software application is always a challenge, and security is especially so, as poorly made decisions made in the early design stages and in early releases can lead to years of confusion for clients and end-users. By keeping your Java EE roles simple, trying to cover all of the security requirements by defining the fewest roles possible, and by avoiding the creation of hybrid LDAP groups to sidestep the prescribed Java EE roles that are defined with pre-packaged enterprise software, will help simplify the task of managing security and make life much easier for operators, developers and end users.

What tips do you have for better managing security? Let us know.