Year Of Security for Java – Week 31 – Access Control (1)

No Gravatar

What is it and why should I care?

Access control, also known as authorization, is the step that comes after authentication. Access control is the process of “mediating access to resources on the basis of identity” [from here]. It assumes you have determined the identity of the user (whether known or anonymous) and are now making decisions about whether or not that user (or a group they represent) can access a given resource.

Access control is one of the most exploited security controls in many systems. Often times access control is not performed well or maybe not at all. When it exists, many times it is not applied consistently, and therefore leaves large uncovered gaps in the security of an application.

There’s a good bit to unpack in the statements above, and there are different models for access control (MAC, DAC, RBAC, etc). However, there are some basic concepts for access control that generally need to be met in web applications, and those are the ideas I plan to lay out in the next few posts.

What should I do about it?

Note: This is part 1 of 3 in the sub-series related to access control. More is coming.

Note: While there are plenty of helpful best practices for implementation that I’m not going to touch on (like: do not depend on the client at all for access control decisions, apply principle of least privilege, centralize routines for access control, use a mechanism that allows simple policy changes, etc.), I’ve added some references at the bottom that include some of these recommendations. Please read if you’re building access control systems or if you’re just interested.

Given the caveats in the notes above, what I would like to talk about for this first post is one way that you should consider limiting your users’ interactions with your application: by functionality. Limiting users by functionality simply means that certain users (or groups) can access certain functions on your site.

The first popular framework that made this really simple was Struts 1. In Struts 1, you could configure which roles had access to which actions in your application with a really simple mechanism that looked something like this:


    ...

J2EE in general has had a mechanism (roles and security constraints) that allows you to perform this function for a long time, but it can be a little clunky and requires a lot of configuration relative to the Struts 1 mechanism.

In more recent history, the Spring framework picked up the Acegi project and renamed it Spring Security (ok, not that recently). Spring security has a large focus on authorization since that’s one if it’s core functions.

Many frameworks provide a way to accomplish this in their own specific way, but you just have to be aware of the mechansims (or lack thereof) of any given framework you’re using.

The key capabilities you will generally want at a minimum are feature and function management.

What I mean by feature management is a mechanism to control access to several functions at once grouped by general capability area. For instance, in SpringMVC, you might have a TradeController that controls access to all of your trading features within your application. Certain users/groups may need no access whatsoever to that feature, so having the capability to exclude components/features of the application to whole subsets of users is nice and simplifies management.

Function management means you can control access to the individual function that is being called for a specific request, ie. tradeShares(). Having the ability to specify which users/groups may access a specific function is critical.

A couple of finer points here:
1. If you only get one or the other (feature/function management), pick function management – you need the specificity.
2. If you get both, be careful regarding inheritance. The most flexible system I’ve seen thus far (that doesn’t get you into a whole heap of trouble) is allowing inheritance from the feature to the function IFF the function does not specify any allowed users/groups of its’ own. Otherwise, you get into merging allowed users/groups, and that can get messy, not to mention very confusing for those trying to do the right thing for security.

In conclusion, limiting users and groups by access to features and functions is a good first step to providing good access control. There are other ideas coming in the next couple weeks to watch out for and handle additionally, but this is a good start.

References
———–
https://www.owasp.org/index.php/Category:Access_Control
https://www.owasp.org/index.php/Guide_to_Authorization
https://www.owasp.org/index.php/Access_Control_Cheat_Sheet

Be Sociable, Share!

Technorati Tags: , , , ,

2 thoughts on “Year Of Security for Java – Week 31 – Access Control (1)

Leave a Reply

Your email address will not be published. Required fields are marked *