Access control

I’m trying to learn some more about the security model in MODx and how to use it for making my own components. I guess what I really need is to read the continuation to this one: http://svn.modxcms.com/docs/display/revolution/Using+Custom+Database+Tables+in+your+3rd+Party+Components describing how to control access to the functions I create. But I will settle for asking questions in here:

- I’m guessing I need to extend modAccessibleObject in my schema instead of xPDOObject if I must control access to the data in the tables? Is the same relationship valid when comparing modAccessibleSimpleObject to xPDOSimpleObject?

- How do I link permissions/policy properties/whatever to functionality I create? How much of this is handled in the framework, and how much is up to the individual implementations?

- Is it possible to limit a permission to one or more instances of objects?

- Is there native support for assigning an owner to an object? And by the way, how do I get the active user ID?

Ok so here is what I have found out until now:

- Simple one first: $xpdo->getLoginUserID() to get active user ID.

- Looks like the link between permissions and actions must be made in the implementation by overriding findPolicy(). Looks like this is the key if I need to implement owner-awareness in my app, likewise for limiting permissions to object instances. Getting warmer?

- Looks like checkPolicy() unwraps several layers when processing the array returned from findPolicy(). Is there a description of that format? I can’t seem to find it in the API description.

Seems I forgot an important point:

- Simple database operations are guarded by "load", "save" and "remove" as keys for the read, write and delete low-level operations in the database. So as long as the findPolicy() implementation actually processes policies, these will be automatically checked.

Quote from: Jacob at Oct 03, 2009, 06:05 PM

- I’m guessing I need to extend modAccessibleObject in my schema instead of xPDOObject if I must control access to the data in the tables? Is the same relationship valid when comparing modAccessibleSimpleObject to xPDOSimpleObject?

Correct.

Quote from: Jacob at Oct 03, 2009, 06:05 PM

- How do I link permissions/policy properties/whatever to functionality I create? How much of this is handled in the framework, and how much is up to the individual implementations?

This depends on how you implement findPolicy().

Quote from: Jacob at Oct 03, 2009, 06:05 PM

- Is it possible to limit a permission to one or more instances of objects?

Sure, this is how modAccessResourceGroup limits access to Resources in specific Resource Group instances.

Quote from: Jacob at Oct 03, 2009, 06:05 PM

- Is there native support for assigning an owner to an object? And by the way, how do I get the active user ID?

In MOD you get the active user ID from $modx->user->get(’id’), but there is not built in support for ownership on all objects. This is up to your object i implementation to define.

Quote from: Jacob at Oct 04, 2009, 10:55 AM

- Simple one first: $xpdo->getLoginUserID() to get active user ID.

See above, modX::getLoginUserID() is there for legacy code support and you should use $modx->user->get(’id’) instead.

Quote from: Jacob at Oct 04, 2009, 10:55 AM

- Looks like the link between permissions and actions must be made in the implementation by overriding findPolicy(). Looks like this is the key if I need to implement owner-awareness in my app, likewise for limiting permissions to object instances. Getting warmer?

You are getting downright hot!

Quote from: Jacob at Oct 04, 2009, 10:55 AM

- Looks like checkPolicy() unwraps several layers when processing the array returned from findPolicy(). Is there a description of that format? I can’t seem to find it in the API description.

Not really but let’s see if I can describe what’s going on here for a little clarity. Each access control entry that checkPolicy() processes defines a principal, a target, and a policy. checkPolicy() simply iterates through the access control entries defined for an object and looks for matching targets defined in a principal’s attributes. Then it iterates the principal’s attributes for any policies that match and for which the principal has enough authority to access. Once a match is found, it checks the policy attributes defined in that access control entry against the criteria passed to checkPolicy(). If all the attributes in the passed criteria are available in the principal’s list of attributes, then checkPolicy succeeds, otherwise it fails.

I know this doesn’t fully describe a format, but we can go from there if you have additional questions...