Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm working on the access control component of a complex web application. One of the goals is to have a strictly defined model for who can do what, but I can't find an existing model that meets our needs.

The problem is to define a system I can query with pairs of objects (typically a user and something else, but not necessarily) to find the appropriate level of access according to the application's structure. These 'objects' are - in my case - 'models' in an MVC-style webapp. Say one of the models is a blog, and another is an interest group of some sort; a blog can belong to a group, a user can belong to a blog or a group and group can belong to another group. A example of the sort of rules I want to use: 'a user can post comments on a blog if the user is a member of a group to which that blog belongs'; 'a user can view a blog if the user is a member of a group which itself is a member of a group to which the blog belongs', and so on.

These cases are easy enough to implement explicitly in code, but I'd like a formal model like RBAC and friends. Does such a thing exist? If not, is there a good reason why?

(Edited for - hopefully! - clarity)

Further edits for more clarity:

Courtesy of Dennis' link, a definition of RBAC:

Unlike ACLs, access to a resource is determined based on the relationship 
between the requester and the organization or owner in control of the
resource; in other words, the requester’s role or function will determine 
whether access will be granted or denied.

In these terms, I'm interested in more complex 'relationship[s] between the requester and the organization ...', along with similar relationships between the organizations and resources of the system: rather than each resource having a list, set by its owner, saying 'such-and-such a role has such-and-such a level of access', I want the level of access to be determined by the (possibly complex) relationship between the user and the 'owner' and between the owner and the resource.

Conceptually I have a graph that includes users, organizations and resources, and I want the access control rules to be determined (in part) by the structure of that graph.

Edit: the sort of thing I'm talking about is quite similar to the 'policy predicates' in S4.2 of http://dspace.ucalgary.ca/bitstream/1880/47933/1/2010-959-08.pdf.

share|improve this question
    
Actual model depends on your organizations and resources, and the approach can be RBAC: en.wikipedia.org/wiki/Role-based_access_control but there is also en.wikipedia.org/wiki/Multilevel_security. –  Andrew Smith Jul 25 '12 at 7:44
add comment

4 Answers

There is generally not a single formal model you can just adopt -- and for a good reason. The right access control structure needs to depend upon the specifics of your application, so there is no one-size-fits-all answer.

In general, figuring out how to define access control involves looking at a few questions:

  • What are the resources I need to protect? What are the resources that are most security-critical? This will depend upon your application, but it might be things like individual blog posts, the comments on a blog post, or the theme/layout for a particular blog.

  • What are the actions one can perform on those resources? Next, define the operations or actions someone might want to perform on those resources. Often these are the basics like view (read), edit (write), create, and delete.

  • Who are the individuals who might want to perform such an action on such a resource? In access control parlance, these are sometimes called the "principals". For instance, this might be the set of users with accounts on your site (each user is a principal). You might also define groups (e.g., all administrators; all users associated with a particular blog), or you might allow users of your site to define groups.

  • What limits do I want to put on these actions? You can define a security policy. One way to define a security policy is to determine, for each resource, what actions each principal can perform on that resource. This might be described more concisely in terms of groups (e.g., any administrator can edit any blog post). You can decide whether a single, fixed security policy is more appropriate for your application, or whether it is more useful to allow the users to determine the security policy. Often it is way too much to expect users to write down all allowed combinations of (principal, action, resource), so you'll need to think about what are some common policies that might make sense for your application, to make it easier for users.


A few other comments.

I would suggest you look at some other example applications that are similar to the one you want to build, to see how they do access control. There are many blogging platforms; why don't you take a look to see how they allow blog administrators and bloggers to control access to the blog? See what you like and what you don't, and what seems like it works well for users and what doesn't, and learn from that.

Also, I want to introduce you to the concept of user-driven access control, where instead of you (the software developer/administrator) trying to set a security policy for your site, you allow users to determine their own security policy through their own actions. For instance, each blog post might come with its own "view" link that users can share with others; if you share this link with Alice, then Alice will be able to view the blog post. You can include a random unguessable token in this link, and then knowledge of the URL is all that is needed to view the blog post. As another example, each blog post might come with an "edit" link that the blog owner can share with someone else to let them edit the blog post collaboratively -- think how you can share a Google Docs document with someone else, for instance. In this model, each of these links is a capability that grants authorization to perform a certain action on a particular resource or collection of resources. In some circumstances, this approach can be useful, because it provides users with the flexibility to determine their own secure sharing patterns.

share|improve this answer
    
Thanks for your answer D.W.. I have a pretty clear idea of the answers to all those questions, but it's the last that's proving troublesome - the 'limits on these actions' need to be something more sophisticated than just a list of <principal, action, resource> triples - I want to be able to say that all principals related to a resource in such-and-such a way have this or that action allowed, with 'related' defined in the terms of my question. I guess that comes under 'common policies', but I can't find a proper way to express these sorts of policies. –  jimw Jul 24 '12 at 21:29
    
@jimw- OK, makes sense! It might help to get more specific about exactly what you want to do. The question is very abstract, which makes it hard for me to provide more concrete advice... Then again, maybe I just work better with specific examples than with generalities. –  D.W. Jul 24 '12 at 21:34
    
A very simple concrete example: in a UNIX filesystem, I might want to specify that 'a user has read and write permissions for every file underneath the user's home directory' (ignore symlinks!) and that 'a user has read permissions for every file underneath any directory the user owns'. That's the kind of rule I'm talking about, but I'm looking for a formal model like RBAC that takes in the whole general case of that-kind-of-thing. A bit vague, I know, but I've never seen a system with these properties, so I don't really know how to describe it clearly. –  jimw Jul 24 '12 at 21:52
    
@jimw, those rules are easy enough to code up. I'm not sure what the issue is. When you write a web application, you are responsible for defining, implementing, and enforcing the access control policy that you want to enforce. (As far as a formal model: like I said, I believe what you are looking for does not exist. You should not expect there to be a one-size-fits-all formal model that does what you want. The access control model is inherently application-dependent.) –  D.W. Jul 24 '12 at 23:44
    
P.S. @jimw, Here is one paper in the research literature you might find interesting: GuardRails: A Data-Centric Web Application Security Framework. See particularly the material on access control (e.g., Section 3). –  D.W. Jul 24 '12 at 23:46
show 1 more comment

Replace the word "group" with "role", and what you described is RBAC, or at least the hierarchical part of it. Think of it like this:

  • Users are placed into groups (roles).
  • Individual groups (roles) may have any number of privileges.
  • Access to objects is decided by the accessing entity's group (role).
  • Certain groups (roles) may have child groups (roles).
  • A parent group (role) has, at minimum, the same privileges as a child group (role).
share|improve this answer
    
Not quite, at least not as I see it: RBAC schemes allow users to be hierarchically classified into groups, but what I want to do is more complex. I have users and the access-controlled objects within groups, and many different types of groups with different relationships, amongst them; I then want to define permissions rules based on the various relationships that might link a user and an object. Does that make sense? I suppose it's a much generalized case of something like the LinkedIn system, in/out of my network and that sort of thing. I think I've explained it poorly... –  jimw Jul 24 '12 at 16:02
add comment

(I am aware this is not exactly pre-written, but its better than a ground-up implementation)

Perhaps you should use the fine-grained control of SQL Permissions.

The group management is going to be manually written and vetted code. You will need to make your own grant command creator which creates the SQL users based on their groups.

Once complete, you can pass the SQL user credentials to your less vetted code, thereby securing what SQL data it can reach. You may also wish to use the operating system to restrict the file-level permissions of the less vetted code.

Note that the SQL users do not need to be one per application user. They can be one per permissions checksum, they can be dynamic, totally recreated on startup. That is up to you.

I would however suggest you add more details to your question. Do you need file-level permission management in your webapp, SQL-level permissions, something else?

share|improve this answer
    
Thanks, that's extremely interesting. I've added more detail to my question, hopefully it's a little clearer now - the goal isn't access control per se, but applying arbitrary rules to find out what level of access a user should have to particular objects. –  jimw Jul 24 '12 at 17:14
    
What programming language? –  George Bailey Jul 24 '12 at 19:19
    
I've implemented the prototype of the access control logic in Clojure, but I'm looking for a formal model rather than code or library support - implementing an ad hoc scheme is straightforward, but for this application I'd very much like a proper formally-specified access control model. –  jimw Jul 24 '12 at 19:22
add comment

Try this for a start: csrc.nist.gov/news.../PvM-Model-Survey-Aug26-2009.pdf

What I can tell you is to really, really think about this. Many apps start out as proof of concept; like a shell script in decades past - and are so useful they get deployed. Those early architecture decisions can really, really effect later scalability and maintainability; when thousands, tens of thousands or more people use the system/tool designed for a few hundred.

Identity management and access control are the two worst offenders. Its actually best if you can use something like SAML assertions and build a separate identity and access control point. In the long run you will be able to maintain this and scale to the need. Its seems expensive from a performance perspective at the earliest stages - but in the long haul its cheapest.

If you cant' do that be very conscientious to keep all identity and access control code together so that you can refactor it easily to meet demands.

Be sure to check out the OWASP Access Control Cheat Sheet: https://www.owasp.org/index.php/Access_Control_Cheat_Sheet

Best of luck.

share|improve this answer
    
Thanks for the advice Dennis, I appreciate it. The NIST survey is particularly useful. I thoroughly agree about the dangers of rolling one's own access control, but as far as I can tell that's standard practice for web apps, even 'enterprise' ones: these sorts of rules exist (cf. linkedin etc.), but appear to be implemented explicitly in code on an ad hoc basis. Thanks again for your answer, hopefully I'll find some gold in the NIST paper. –  jimw Jul 24 '12 at 20:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.