7.20.2007

Instance-Level Access Control

In the world of Twitter, OpenID, and Web 2.0, you might expect to find this in an archive from 2004 - but here it is. If you don't want to read all of it, the bottom line is:
  1. The failure to adequately define and specify terms renders the the development of security software an unknown and thereby risky venture,
  2. Instance Level Access Control is typically used to mean access control that is more specific than what you have today, and
  3. Application developers and users don't care about fuzzy terms if the software they're using does something useful and/or is fun.
The solution
  1. Define all terms, especially if they pertain to security, risk, privacy, or compliance; and the applications that feature them.
  2. Do #1 even if you think "everyone" knows what you mean. They probably don't.
  3. Instance Level Access control generally means understanding a protected resource at the level at which its expressed by an application. If so, it reflects the level at which the semantics of access control can be captured enforced.
Instance-Level Access Control?

I contend that in application architecture and for a host of non-security specific technologies, a certain degree of fuzziness of terms its not harmful and may even aid use and adoption. An user discovers capability despite or perhaps in spite of what it is called, and just appreciates the fact that it does something useful for them.

Whereas this fuzziness may be a great strategy for the conceptualization, design, and development of certain types of application, it has deleterious effects on the realization of security capability, generally inhibiting the goal of risk mitigation. This is simply because risk is proportional to uncertainty.

Consider the Federal Financial Institutions Examination Council (FFIEC) and its regulations around an institutions "Customer Identification Program" (CIP). While the intent is clearly to have in place mechanisms by which an institution can reasonably identify its customers, (no complaint there), various vendors have invented new terms like "2nd Factor" or "Multi-Factor" authentication.

Some of the new "2nd factor" and "Multi-factor" authentication products fulfill the regulation while providing additional security capabilities not required by FFIEC. One of these is a popular vendor's version of mutual authentication which is a potential new threat vector and reported to be exploitable by phishers. While perhaps a good subject for a subsequent post this particular technology is only an example. My point is that the arbitrary use of previously precise terms leads fuzzy product targets and the misunderstanding of their characteristics. This results in a myriad of negative consequences for both product designers and their consumers.

So what of Instance Level Access Control? Bottom line is that I don't know what people mean when they tell me they need "instance level access control,"
(If you do, please comment!) because each has person/organization/document means something different. A security document's failure to adequately define its terms, or to assume that it shares with the reader a common understanding ends in predictable, if unfortunate results.

At the risk of being just one more voice in the cacophony (don't you talk about instance level authorization at your dinner table?) let me go back to a time when J2EE security started to address its access control requirements with a model that included users and their identities in access control decisions, rather than just the system's code as system entities.

The original model provided for access control at the level of Java classes and methods on those classes. The result was that you could determine unambiguously (most of the time) whether or not a particular combination of user, class, and method was implied by a particular request. The "instance level" problem was (and still is) that there was (is) no way to distinguish between an object named "Ford Motor Company" as an instance of the class "AutoManufacturer," from an object "Bayerische Motor Werke" also of the class "AutoManufacturer." This meant that there was (is) no way at the EJB container to enforce policy whereby one set of users could work only with Ford (objects), and the other set only with BMW.

Java Authorization Contract with Containers (JSR 115) promised to correct all this. What it gave us was the previous J2EE model (must maintain backward compatibility of course!) - and what my friend refers to as "a hole in the container through which to push stuff." This "hole in the container" is expressed in a "context handler" which is code you or your staff write to tell the container how to perform access control on particular classes. This "hole" provides a mechanism to distinguish one object from another, by descriminating on instance data in the class, maybe a field called "Name" for example. Thereby you can write authorization policy which differentiates between two different objects (distinct class instances) of the same class.

But note, there is nothing in JACC that gives you general Java object instance level access control, unless you consider an EJB method's parameters to define an instance. My friend also likes to point out that container based security - beyond the specification's mandatory container types (Web, EJB, etc.) - is about externalizing into the container based mechanism code you'd have to write inside your applications to enforce access control policy anyway.

One might envision a JACC based context handler that might be able to introspect all the public (and dare I say private?) fields in an object, and then based on some meta-data be able to divine what to do with it. But then I've thrown OO's encapsulation out the window, that we tend to consider good qualities of object oriented design and development.

The example may seem strained - but this is more an example perhaps of overpromising and under delivering. I contend the "original" instance based problem was as I have characterized it - distinguishing two distinct instances (objects) of the same class at run time. JACC aimed and didn't achieve it (yet). I think the example is relevant because Instance Level or Instance Based authorization was given as primary objective for the specification. At best, instance based access control in JACC is under-specified; and it certainly isn't delivered with the mandatory compliance requirements it describes.

This isn't a slam of J2EE security. It is intended however to distinguish between what is suggested by terms such as "delivers instance based security" and what it actually does. It is a useful marketing term, if you want to imply capability your customer's can't yet achieve but for which they'd buy your product if they could. My marketing friends tell me this is a cynical view. I suggest it may be cynical of them to say so.

If you've made it this far, you're either an obsessive geek or will read anything. Thanx.

~r

2 comments:

Ivan said...

The other things that get brought up when we discuss "Instance Level Access Control" are:
- Meta-data driven access control. An example is "If Chuck is the 'owner' of resource X, he should be able to do operations A,B&C". Owner is not an explicit attribute of the resource, but is in the metadata.
- Incorporating object and transaction attribute values and rules into access decisions, e.g. "Chuck can only approve transactions under $5000 for accounts in the US."

Ivan

Dori said...

This is great info to know.