[cap-talk] Architectural Choices: How to migrate from IBAC to OBAC = Object-Based Access Control?

[Jed Donnelley]

On 11/14/2007 10:51 AM, Karp, Alan H wrote:
> MarkM wrote:
>> I've lately been happy using "identity-centric" vs
>> "authorization-centric". I then explain that ACLs, RBAC, PBAC, and MLS
>> are all identity-centric. Capabilities, Polaris, SPKI, and BitFrost
>> are authorization-centric.
>>
> I like the "-centric" term, but I think I'll go with
> authentication-centric versus authorization-centric.  The use of N/Z was
> to fit that into the BAC nomenclature.  I can avoid that rathole with
> the "-centric" terminology.

I don't like the "-centric" terminology.  It seems to me
to obscure things more than to clarify them (more below).

With regard to:

On 11/14/2007 10:23 AM, 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. 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?"

I argue that Role Based Access Control is a form
of Identity Based Access Control.  It is still based
on authenticating to an identity and then using that
identity for access control (authorizations).  It isn't
just identity-centric, it is identity based.

I'm agreeing with Marc Stiegler.  I agree that IBAC
and ABAC are easy to understand (more on ABAC below).
Anybody who asks about RBAC can easily understand that
it is a type of IBAC.

"Identity Based" is very concrete and easy to understand.
"Identity-centric" to me sounds wishy washy, hard to get
your hands on, sort of, ...

Access Control Lists (ACLs), Role-Based Access Control (RBAC),
Context-Based Access Control (CBAC), and Trust-Based Access
Control (TBAC) are all aspects, types, or forms of Identity-Based
Access Control.

<aside - not to be distracted by:
Multi-Level Security (MLS) usually incorporates Identity
Based elements (i.e. people have clearances and objects
have levels), but MLS is a broader concept that can
label entities that are not "based" on Identities (e.g.
active objects, ports, etc.).  For example, the active
objects in the NLTSS system (processed) all had clearances
that were independent of being associated with any identity.
Communication ports also had levels.
/aside>

My opinion is that we should stick to the simplest
underlying notions of:

Identity-Based Access Control (in all it's forms
                               and variants)
vs.

Authorization-Based Access Control


However ...  Now that I'm rolling on this topic:

What about the term "Authorization-Based Access Control"?

To me that expression sounds like a meaningless
tautology.  Of course access control is "authorization"
based.  Either the access is authorized or it is not.
What does using the adjective "Authorization-Based"
tell me about an Access Control scheme?  Next to
nothing in my opinion.

I don't want to necessarily shake a big and hard
fought over boat here (too much), but if I was
going to work on access control terminology to
assist our cap-talk goals, what I would work on
is the ABAC term.

Isn't what we're really talking about when
we refer to "Authorization-Based Access Control"
something more like Token-Based Access Control
or Parameter-Based Access Control (not to
mention Capability-Based Access Control)?
To minimize acronym collisions, what about
Object-Based Access Control, OBAC?

(Oh sure, I know about Organization-Based
Access Control, but then we also have
Attribute-Based Access Control as ABAC...
And yes, I know that all access control is
about access to objects.  I believe Token
instead of Object would point more directly
at the underlying technology but ... more
below.  Sigh, I also know that the
term "Object-Based Access Control" has
been used before in other contexts -
in a minor way so far as I can tell
that would likely not clash).

To me the notion of Identity-Based Access
Control is abundantly clear in all it's
forms, implementations, and nuances.

I also well understand Capability-Based
Access Control in quite a variety of
implementations and nuances.  Avoiding
a seeming technical term like "capability"
seems reasonable.  Referring to Capability-
Based Access Control as Object-Based Access
Control (OBAC, other possibilities?) makes
some sense to me.  It seems to me to have
some advantage in binding to the "Object"
and Object-oriented bandwagon.  It also
seems to me to say more about the underlying
technology.

Referring to Capability-Based Access Control
as "Authorization-Based Access Control" makes
no sense to me.  To me that expression sounds
like fuzzy logic and does our efforts a
disservice.  Perhaps it does serve to hide
from fears about 'loose' objects, but the
underlying technology will ultimately
become clear.  I believe we need to face
those fears squarely.  Facing them as
communicated "objects" (unsaid that they
are actually object-references, capabilities)
seems much clearer to me.  When I see
people exposed to the Authorization-Based
Access Control expression for the first
time I see eyes glazing.  At least Object-
Based Access Control would generate a
little light.  I think Token-Based Access
Control would be even clearer, though
there are trade-offs.  Thoughts?

I believe I understand and appreciate the
distinction that MarkM makes between permissions
(e.g. as granted by object references) and
authorization (essentially the closure of
access available through the underlying
access control scheme - e.g. through
existing capabilities or ACLs).
E.g. if I give you permission to read
from a directory containing capabilities,
I am actually authorizing 'you' (might
be an person or an active object) to
access all the objects in the directory,
because the directory server will grant
you the contained capabilities in response
to requests from 'you'.  If I put you on
the ACL for a directory with write access,
I give you the authority to destroy all
the files in that directory (among other
things possibly).

I don't know if there is a connection between
that generalization from 'permission' to
'authorization' and the ABAC term, but for me
using the ABAC expression to describe the
token based alternative to Identity-Based
Access Control mechanisms obscures what is
really being contrasted.

Whew.  I'm glad I finally got that one off
my chest.  Naturally I'm interested to
hear comments.  Just expressing my
opinion.  I wasn't around when the
ABAC term was coined, so I can't be
expected to have all the background.
Perhaps it might be worthwhile to raise
that discussion again in this context?

--Jed  http://www.webstart.com/jed/