Is there an access-control model defined in terms of application structure?

Question

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.

Answer 1

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.

Answer 2

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).

Answer 3

(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?

Answer 4

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.

Answer 5

Water has flown under the bridge of "authorization". I'm glad to say that there is a well accepted model that does just what you are looking for.

It's called ABAC or attribute based access control and it is a natural evolution of role-based access control (RBAC).

Where, with RBAC, you focus on the user nearly exclusively, with ABAC you can consider attributes of the user, the resource, the action, and even the context (time of day...). Your authorization is no longer about who you are. It's about Who, What, When, Where, Why, and How.

NIST has been doing a lot of investigation in the ABAC space and they've gathered their notes and reports on their ABAC project site.

XACML, the eXtensible Access Control Markup Language, is an OASIS standard (the same body as the one behind SAML) which defines:

• an authorization architecture
• a policy language, and
• a request/response format

that can be used to implement ABAC. In short XACML implements the model put forward by ABAC.

The best thing about ABAC and XACML is that it is technology-neutral. It works on pretty much anything meaning that you can use it for access control on APIs, web services, ESBs, portals, and even databases.