Piping dynamic data into an interpreter of your implementation language is usually a bad idea, since it escalates the potential for data corruption into a potential for malicious application takeover. In other words, you are going out of your way to create a code injection vulnerability.

Your problem can be better solved by a rules engine or maybe a domain-specific language (DSL). Look those concepts up, there is no need to reinvent the wheel.

I did this, and I recommend that you don’t.

What I did was write all the business logic in Lua, and stored that Lua script in a database. When my application started up it would load and execute the script. That way I could update the business logic of my application without distributing a new binary.

I invariably found that I always needed to update the binary when making changes. Some changes were in the Lua script, but I’d invariably have a list of changes that needed to be made, and so I almost always ended up having to make some changes in the binary and some changes in the Lua script. My imagination that I could avoid distributing binaries all the time simply didn’t pan out.

What I found much more helpful was to ease the distribution of binaries. My application automatically checks for updates on startup, downloads, and installs any update. My users are thus always on the latest binaries that I’ve pushed. There is almost no difference between a change in the binary and a change in the scripts. If I did it again, I’d put even more effort to making the update seamless.

I would not have the database contain code. But you can do something similar by having the database contain function names and then using reflection to call them. When you add a new condition, you have to add it to your code and your database, but you can combine conditions and parameters that get passed to them to create quite complex evaluations.

In other words, if you have numbered departments, it would be easy to have a UserDepartmentIs check and a TodayIsAfter check and then combine them to have a Department=2 and Today>03/15/2016. If you then want to have a TodayIsBefore check so that you can end date the permission, you have to write the TodayIsBefore function.

I haven’t done this for user permissions, but have done it for data validation, but it should work.

XACML is the solution you are really looking for. It is a type of rules engine that is focused on access control only. XACML, a standard defined by OASIS, defines three parts:

• an architecture
• a policy language (which is really what you want)
• a request / response scheme (how you ask for an authorization decision).

The architecture is as follows:

• the Policy Decision Point (PDP) is the core part of the architecture. It is the component that evaluates incoming authorization requests against a known set of policies
• the Policy Enforcement Point (PEP) is the piece of code that protects your application / API / service. The PEP intercepts the business request, creates a XACML authorization request, sends it off to the PDP, receives a response back, and enforces the decision inside the response.
• the Policy Information Point (PIP) is the component that can connect the PDP to external sources of data e.g. an LDAP, a database or a web service. The PIP comes in handy when the PEP sends a request e.g. “Can Alice view doc #12?” and the PDP has a policy that requires the user’s age. The PDP will ask the PIP “give me Alice’s age” and will then be able to process the policies.
• the Policy Administration Point (PAP) is the place where you manage the entire XACML solution (defining attributes, writing policies, and configuring the PDP).

Here’s what your first use case looks like:

/*
 * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
 * 
 */
 policy departmentOne{
    target clause department == 1
    apply firstApplicable
    /**
     * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
     */
    rule allowFooBar1{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }

 }

Your second use case would be:

 /*
  * "All users in department 2, if the date is after 03/15/2016, can VIEW resource FOOBAR-2, else not authorized"
  *  
  */
  policy departmentTwo{
    target clause department == 1
    apply firstApplicable
    rule allowFooBar2{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and currentDate>"2016/03/15":date and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }
  }

You can combine both use cases into a single policy by using references:

  policyset global{
    apply firstApplicable
    departmentOne
    departmentTwo
  }

And you’re done!

You can read more on XACML and ALFA from:

• the XACML Developer’s Blog
• the XACML Developer’s YouTube channel

What you really want here is XACML. It pretty much gives you exactly what you want. You don’t necessarily have to implement the full architecture with all the roles being completely separated… if you only have a single application, you can probably get away with integrating the PDP and PEP into your app with balana and the PIP is whatever your existing user database is.

Now, anywhere in your app you need to authorize something, you create a XACML request which has the user, the action, and the context, and the XACML engine will make the decision based on the XACML policy files you’ve written. These policy files could be kept in the database or on the filesystem, or wherever you want to keep the configuration. Axiomatics has a nice alternative to the XACML XML representation called ALFA that’s a little easier to read than the raw XML, and an Eclipse plugin to generate XACML XML from ALFA policies.

We did this at my current company, and we’re very happy with the results.

Our expressions are written in js, and we even use them to restrict the results the users can get from querying ElasticSearch.

The trick is making sure that enough info is available to make the decision, so that you can really write whatever perms you want without code changes, but at the same time keeping it fast.

We are not really worried with code injection attacks, as the permissions are written by those that have no need to attack the system. And the same applies to DOS attacks like the while(true) example. The admins of the system have no need to do that, they could just remove everybody’s permissions…

Update:

Something like XACML seems to be better as a central auth management point for an organization. Our use case is slightly different in that our clients tipically have not an IT department to run all that. We needed something self-contained but tried to preserve as much flexibility as possible.