CMS, Content, and Joomla Access Policies

[garyamort]

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]

[Mark Dexter]

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

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/2SJqbDlpkh4J.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[elin]

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

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[garyamort]

On Wednesday, April 18, 2012 12:06:39 AM UTC-4, elin wrote:

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.

Thanks, I prefer rambly and informative. :-)

#__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. 

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

[elin]

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