[cap-talk] Architectural Choices for Security: terminology

David Hopwood david.hopwood at industrial-designers.co.uk
Thu Nov 15 20:04:24 EST 2007


Karp, Alan H wrote:
> Marc Stiegler wrote:
>> Truthfully, I think the right term to use is still IBAC, which is the
>> term Alan has historically used. Referring to "Identity Based" as IBAC
>> and Authorization Based as ABAC is instantly understood by everyone.

I'm not so sure. In an ABAC system, what determines whether a subject
is authorized to perform a particular request?

By saying 'ABAC', we normally mean to imply a specific answer: that
references (object designators) carry authorization, and that they are
unforgeable and transferrable between subjects. But none of this is
clear from the term 'ABAC' itself.

Also, by IBAC we don't mean just any use of identity; we mean that for
each request the system performs an access check based on the requesting
subject's identity. Most (all?) of the criticisms we have of IBAC systems
arise from consequences of checking requestor identities. Other uses of
identity (such as in petname systems, for instance) don't have the same
consequences.

In Java (as designed by Sun, not Joe-E), the security of the system
relies both on some references carrying authorization, and on requestor
identities being checked via stack introspection. In Plash, there are
both capability-based access controls, and requestor-based controls
inherited from Unix. If we understand these systems as being based on
multiple security mechanisms, there's no problem. But since other terms
ending in 'AC' have most often been used as mutually exclusive
categorizations of *systems*, rather than mechanisms, it is too easy
to assume that 'ABAC' and 'IBAC' are meant in the same way.

>> But unless you are talking to the smaller circle of people who speak
>> of AuthN and AuthZ, the N and the Z need such a long explanation that
>> it gets in the way of the discussion. NBAC and ZBAC is a total 
>> failure for an "elevator pitch", for example, unlike IBAC and ABAC.
>
> I agree with everything you say, but I still think we need a more
> general term.  As I'm talking about IBAC, I can just see them thinking
> "What's wrong with this guy?  Hasn't he ever heard of RBAC?"

RBAC is a special case of IBAC: for each request an RBAC system performs
an access check based on the requesting subject's identity (mapped to
a role).

If we defined IBAC to require that only direct subject identities can
be used in policy specifications, then almost nothing would be IBAC --
e.g. ACL systems that support groups would not be, since a group isn't
a direct subject identity.


In any case, if we are going to change 'ABAC' and 'IBAC', let's make sure
that we are changing them to something that is clearly an improvement,
and on which we have a concensus on this list. I don't think there is a
concensus for any of the terms suggested so far (including the '-centric'
terms).

At risk of repeating myself, I view the critical distinction as being
between access control mechanisms in which references carry authority,
vs. those based on checking of requestor identities. I don't have a
concrete terminology suggestion at the moment, but I would be happy with
any terms that made this distinction clear.

-- 
David Hopwood


More information about the cap-talk mailing list