I'm trying to get a handle on how the CMS implements the Joomla Platform
for access control

What it appears to me is that the CMS breaks up access into 2 distinct
categories, at least for content.

1) Viewing Content
2) All other actions[edit, add, publish/change state, etc]

For 'all other actions' it uses the Joomla Platform Access control system
pretty much as is.  IE it calls the Platform API's and asks if a user has
access to perform a specific action.  
Access Rules are stored in a set of tables:
_associations: This maps a combination of component and
action/task[optional] to a set of rules from ?__rules?  Each rule is either
1 or zero for explicitly turned off or on, and inheritence is used to
determine implicit access levels
__wf_profiles: Defines a set groupings for access rules, so that entrees
from ?__rules? are mapped into profiles.  Profiles map to user groups and
users.  If a type is mapped to a group, the group id appears under types.
 If it is mapped to a user, it appears under users.
__usergroups:  A list of groups which get matched to profiles which get
mapped to associations which are used to determine access
__users: A list of users which get matched to profiles which get mapped to
associations which are used to determine access

Therefore, the basic process is to call the API, it will gather up a list
of all profiles active for a user, then match that against the application
action assoication and grant or deny access.

Because this entire matching process is a lengthy affair, __categories and
__content store the view action in their own records, sort of a mini cache.
 These are the id numbers of the profiles(?) that are allowed to merely
look at the article.  So when determining access to an article, by joining
across __wf_profiles, __usergroups, __users, __category, and __content it
can quickly be determined if the user attempting to view the article has
access to it or not.

If anyone[Elin?] has more detailed information, can you fill in the blanks?
 I ask because in the wiki, much is said about how Platform access policy
is determined, but not much is specified on how the CMS handled content and
categories as a special case[there is some well written and detailed
descriptions of how to MANAGE view level access on the backend and how that
works - but I couldn't find details on the actual implementation]

My understanding is that if you check for permissions at the most detailed
level, (articles for content, category for other components), it will
automatically check all levels for you. So you only have to do one check if
you use the detailed level.

One problem with the current ACL system imo is that it is designed only to
look at the permissions once you have a specific content item. It is not
optimized as far as I know to be able to answer a question such as "what
are the categories that the user has create permission for?". I *think* to
allow for that would some type of mapping table to allow an easy sql query
to get assets by group and permission.

Mark

We do know what categories a person has create permission (or any
permission) for, that is already indicated in the list of available
categories to save to when you create a new article. It's easy enough to
retrieve that list. The problem we have is that we are using the backend
filters in the front end which means we can't say ... give me everything
this user has the right to edit (just like we can't in the back end) and we
also can't use OR only AND in the queries (in the back end notice you can't
select published or archived ... or articles that are either in the fruit
shop category or are public or both.  I actually have phase one of some
work on reducing this problem in the tracker, which takes care of
separating out the archived items which have been bothering put we really
need to do a more thorough rewriting of the articles model to solve some of
these problems.

Ok a bunch of comments on ACL in the CMS.
This is a bit rambly but hopefully some of the pieces will answer your
question.

The CMS not surprisingly implements the ACL from the platform very directly
and with only a few points where probably the authors perhaps would not be
happy.

Profiles have nothing to do with ACL.  They are just what ever you do with
user plugins

#__usergroups is a table defining groups and their relationship to each
other in nested sets. This lets us take advantage of the speed of
transversing in a nested set.

Groups are mapped to both the *seeing* system and the *doing *system. These
are loosely coupled and if you are not careful you can give a permission to
do something on an asset that they can't see.

#__user_usergroups maps each user to one or more groups. Each group can be
considered an identity.
Users can have multiple identities and for a given asset the most
permissive identity holds.

#__viewlevels is the seeing clusters and how groups map to those. What is
important about view levels, and makes them different than the actions, is
that each item (asset or not) that has a view level can have one and only
one. So you many need many view levels to capture all the permutations your
require but you hope that won't be every permutation. All items (contacts,
newsfeeds) have view levels whether or not they have action permissions.

#__users just .. is users with their ids.

Why are seeing and doing separate? Well Louis could certainly tell you what
he was thinking, but my take on it is that there are number of reasons.
1. Seeing permissions applies to a lot more things than assets. For example
modules and menu items are not assets (they are just things that reference
assets i.e. manila envelopes.) yet we do want to control who can see them.
So we need a system for that.
2. Every time you add another action type you add a level of complexity and
there was a lot of sensitivity about both the performance implications and
also how hard it would be for extension developers especially since the
viewing permissions were already there in 1.5. In fact in the UCM work
things are even simpler now, which a real focus on CRUD plus business rules
you can implement.

Why didn't we go down to the item level in all components? Again, I think
it was a combination of not wanting to mandate that for all components and
also concern about performance. We were very worried about potentially
having asset tables with tens of thousands of rows with inefficient nesting.
 I would say that I think we should have a discussion about extending to
item level for all components in the core for 3.0. That will make migration
to UCM for 4.0 that much easier since UCM definitely has permissions at the
item level for  everything in the content table.

Basically in 1.6+ ACL the most important concept is the asset.  in the core
asset types are:
root (global)
component
category
items

If you never use items permission then you will never have to spend the
time to cope with overriding inheritance from the categories.
If you never use category permissions you will never have to spend time
dealing with category inheritance.

The CMS implementation always checks permissions up the branches although
the API actually gives you the option not to do so.
The CMS defaults to soft deny in the absence of other information, again
you could use the api to do it differently if you wanted.

So for performance you want to always stop at the level in the hierarchy
that gives you the granularity you need but no more.
All this checking btw is done with just one visit to the database.

One other thing I will say about implementation in the CMS is that we
attempted to make each action independent of the other actions. For
example, you can have edit.state permission for an asset but not edit. You
can have delete but not edit state.  Again, whether it makes sense to go
down to that level of granularity depends on your situation, but the
infrastructure is there.

Elin

Thanks, I prefer rambly and informative. :-)

Hmm, I'm going to have to digest this.   I'm in the process of setting up
some personal websites where content overlaps from one site to the other[ie
I might post a news article on one website, which should also be posted to
my personal blog]...and being a lazy individual, the idea of retyping stuff
is a pain.   I'd much rather have one Joomla installation with one
database, and share from one to the other in the admin.

I had been looking at an ugly core hack to JDatabase to accomplish this
when it struck me that Joomla! might already come pretty damn close to this
and a single system plugin is all I need[given that I am not concerend
about a shared usertable, it simplifies things].

Provided I create groups for every domain, instead of having to hack
together all sorts of "domain" options, I can simply use the built in ACL
to assign content items, modules, and components to different domains.

All the system plugin has to do after a user logs in is grab the logged on
user object, backup their existing list of access groups/profiles and then
strip out groups/profiles for all the domains which are not currently
active.  Then at the end of the session, before the user object gets saved,
restore those items so they don't get deleted from the database.

In short: Multi-Domains....Joomla! does that.  It lacks an interface for
doing this so right now it would all be manual configuration.  But it's not
too difficult to go through and build an interface for existing
functionality....a heck of a lot easier then building all new functionality.

I'm not sure now if this "one and only one" viewlevel will prove to be a
problem or not....

In any case, it's sure a heck of lot more fun to try to get this to work
then to copy and paste articles between 3 websites. :-)

-Gary

Sebestian from Sebold has implemented multisite just using the native ACL.
 He
 asked for some changes to the module manager t o make that work better
which I believe have been committed or maybe are still in the tracker.
That's so on the admin side too you can give access to people with admin
for one or more but not all sites.

It's amazingly flexible.

Elin