[cap-talk] Ambient authority, authentication and authorization

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Mon Jan 22 10:47:58 CST 2007

Jed Donnelley wrote:
> At 08:44 AM 1/21/2007, David Hopwood wrote:
>>Jed Donnelley wrote:
>>>The common understanding of the authentication/authorization
>>>distinction is that authentication is done once to establish
>>>identity, but then the established identity is used again
>>>and again for authorization.  Authorizations are expressed
>>>in terms of the established identity.  That's where I belive
>>>the problem lies.
>>>You see it throughout the discussion, e.g. on:
>>I've made an attempt to fix that; see what you think.
> Looks like you made a pretty thorough pass through that document.
> At the detail level, did you miss the "users" reference in the second
> bullet under DAC:
> "Access rights and permissions: These are the controls that an owner 
> can assign to individual users or groups for specific resources."
> or did you leave that intentionally as "users"?

I just missed it (also "person" in "Normally, the owner of a resource is
the person who created the resource"). I've rewritten that paragraph.

> Raising up one level, is it just me or is the section in that "access 
> control" page on 'Telecommunication' thoroughly muddled?

Completely. I didn't know where to start fixing it, since it seems that there
is a specialized terminology for access control in telecommunications.
I might slap 'does not cite its sources' and/or 'confusing' section tags on it.

> Now back to the top level discussion of "the opposition":
> Good effort David.  Still, aren't people just going to map subject to 
> user and ignore the suggesting that subjects can be otherwise (e.g. 
> processes or active objects)?

Well, at least the article explicitly tells them not to, and explains why not.

I'm not sure what more we can do (in the context of this article -- or were you
speaking more generally?)

> Consider the section on DAC where it says:
> ___________________________________________
> Discretionary access controls can be applied through the following techniques:
>      * Access control lists (ACLs) name the specific rights and 
> permissions that are assigned to a subject for a given object. Access 
> control lists provide a flexible method for applying discretionary 
> access controls.
>      * Role-based access control assigns group membership based on 
> organizational or functional roles. This strategy greatly simplifies 
> the management of access rights and permissions:
> ___________________________________________
> Should we add a clause there on capability access control?  Perhaps 
> also generalize the heading to something like "Discretionary access 
> controls can be applied through the following techniques" to 
> "Discretionary access controls can be applied through techniques such 
> as the following"?
> I made that change.

[quoting out of order:]
> And then there's this at the end of that DAC section:
> "Access rights and permissions for objects are assigned any group or,
> in addition to, individuals. Individuals may belong to one or many
> groups. Individuals can be designated to acquire cumulative
> permissions (every permission of any group they are in) or
> disqualified from any permission that isn't part of every group they are in."
> Besides the apparently missing "to" in "are assigned any group" (?)
> it seems the use of the term "individual" in the above is standing in
> for user.  Perhaps you did a global search for "user" and missed that one?

The whole of the text from "Discretionary access controls can be applied..."
to the end of that section seems redundant. I replaced it with a single

  Access controls may be discretionary in ACL-based, capability-based, or
  Role-Based Access Control systems.

The original text is on the talk page.

I also added a brief sentence about groups earlier in the article, since they
are orthogonal to both DAC and RBAC.

Oh, while I remember:

  Understanding the differences between [DAC and MAC], as well as specific
  access control methods under each category, is critical for passing the
  Security+ exam.

What is the "Security+ exam", and why should we care? Anyway, the people taking
it have my sympathies if they have to really understand MAC and DAC, as opposed
to just parrotting some learnt definitions.

David Hopwood <david.nospam.hopwood at blueyonder.co.uk>

More information about the cap-talk mailing list