[cap-talk] Architectural Choices: How to migrate from IBAC to ABAC

[Karp, Alan H]

Jed wrote:
> 
> Right.  It "authenticates" the capability, nothing to
> do with the requester.  Is the term "authentication"
> so intrinsically tied up in the IT terminology with
> authenticating an identity (user) that people know
> to apply it in no other context? 

In my experience it is, with the proviso that we include authentication
of role and attributes.  Indeed, the general term is to validate a
certificate to determine its authenticity.  I have yet to run across a
paper or an architecture spec that calls that process authentication.
> 
> The people I've spoken to where the confusion arose
> were thinking of "authentication" as a general term
> such as verifying that a certificate is 'authentic'
> or that a user identification is 'authentic', etc.
> After 'authentication' comes authorization, regardless
> of whether what was authenticated is a certificate or a
> capability or an identity.  For such people (perhaps
> there are few of them that I just happened to run
> into?) there is an 'authentication' step and an
> 'authorization' step in granting any permission
> (authority).  With such thinking, referring to a
> type of access control as "Authorization Based"
> seems to be meaningless.
> 
I agree for those people.  I just haven't run into any of them.  At the
very least, that use of the term authentication appears not to be widely
used in the web services community.
> 
> I wonder if it might be helpful to have a taxonomy of
> the various types of capability-like mechanisms with
> examples of each?  E.g. some capabilities that aren't
> object/capabilities and some of what you refer to as
> "explicit authorization"s that aren't capabilities
> (you gave an example above)?
> 
I believe such a page exists on the erights site.  

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
  
  

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Thursday, November 15, 2007 1:12 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Architectural Choices: How to migrate 
> from IBAC to ABAC
> 
> On 11/15/2007 11:01 AM, Karp, Alan H wrote:
> > Jed wrote:
> ...
> > Verifying that the capability is authentic does not involve
> > authenticating the requester.
> 
> Right.  It "authenticates" the capability, nothing to
> do with the requester.  Is the term "authentication"
> so intrinsically tied up in the IT terminology with
> authenticating an identity (user) that people know
> to apply it in no other context?  Regarding:
> 
> >> I know that's what I hear from many computer security
> >> people for whom the authentication/authorization
> >> steps are a mantra.  I personally don't want to fight
> >> that thinking.
> 
> The people I've spoken to where the confusion arose
> were thinking of "authentication" as a general term
> such as verifying that a certificate is 'authentic'
> or that a user identification is 'authentic', etc.
> After 'authentication' comes authorization, regardless
> of whether what was authenticated is a certificate or a
> capability or an identity.  For such people (perhaps
> there are few of them that I just happened to run
> into?) there is an 'authentication' step and an
> 'authorization' step in granting any permission
> (authority).  With such thinking, referring to a
> type of access control as "Authorization Based"
> seems to be meaningless.
> 
> In this paragraph below, you seem to be limiting
> the term "authentication" to the authentication
> of a user/id:
> 
> > I agree.  I avoid the problem by separating authentication from
> > authorization instead of eliminating authentication.  As I say in my
> > presentations, "Alice authenticates to her domain and gets 
> her set of
> > authorizations.  She presents the correct one with her 
> requests, but the
> > service provider only needs to verify the authenticity of the
> > certificate, not Alice's authentication."
> 
> I understand what you are saying.  However, can you see how
> in that last sentence where you say "...verify the authenticity
> of the certificate, not Alice's authentication." you are
> distinguishing between two sorts of authentication verification:
> 
> 1.  The type that you seem to suggest is a real "authentication"
> (when you refer to Alice's authentication) and
> 
> 2.  The verification of the authenticity of the certificate -
> which for you seems not to be considered an 'authentication'?
> 
> Can you see how this might be a source of confusion for
> people who think of all access control decisions as
> involving an authentication and an authorization step?
> 
> When you then try to distinguish access control mechanisms
> by separating them into "Identity Based" and "Authorization
> Based" types - well, Identity Based is fine, but what
> does "Authorization Based" access control mean if all
> access control involves an authorization step?
> 
> I'm going to leave in the following paragraph to try
> to make sense of what follows:
> 
> >>                 I'd rather just deflect it a bit
> >> by moving it away from Identity authentication followed
> >> by Identity Based Access Control (authorization decisions
> >> based on the authenticated identity - whether using
> >> policies based on Roles or on Context or ...) to what
> >> amounts to Object (reference) authentication followed
> >> by Object Based Access Control - with all the
> >> corresponding values that are so near and dear to
> >> us on cap-talk.
> >>
> > Ocaps is a harder sell than the more general concept of 
> capabilities.
> > Explicit authorizations are more general than capabilities. 
>  I have been
> > trying to use those differences to find the smallest change 
> needed to
> > move people from IBAC (and the others) to ABAC.
> 
> I wonder if it might be helpful to have a taxonomy of
> the various types of capability-like mechanisms with
> examples of each?  E.g. some capabilities that aren't
> object/capabilities and some of what you refer to as
> "explicit authorization"s that aren't capabilities
> (you gave an example above)?
> 
> >> I'm trying to bend our terminology so that it will
> >> make sense to general computer security people who
> >> aren't steeped in capability phraseology.
> >>
> > That's exactly what I do when I describe Alice submitting the
> > authorization certificate directly to the service instead 
> of indirectly
> > via the PDP/PEP.
> 
> OK.  If I'm not getting any traction with the issue
> I'm focusing on with others, I'll just leave it -
> assuming that the "authentication" step is only considered
> with user/id authentication and that "Authorization
> Based" access control has meaning in that the
> authorization is separated from at least the
> user/id authentication.  Seems fuzzy to me, but
> if it makes sense to others I've got no complaints.
> 
> --Jed
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>