[TYPO3-50-general] FLOW3 ACL/Policy syntax discussion

[Andreas Förthner]

Hi all,

in the last two days I thought a lot about the future ACL possibilities FLOW3 must provide. As this is quite a complex 
topic and we don't want to forget anything in the concept I'd like to discuss the current status with you.

I hope you are familiar with the basic concept of resources, roles and privileges. If not just tell me, or look into the 
slides of one of my talks (http://flow3.typo3.org/documentation/slides/).

As I see it now we have three different resource types:

//Method excecutions, see AOP pointcuts for a detailed description
deleteMethods: "method(F3\FooPackage\BasicClassValidator->delete.*())"

//Persisted Objects, syntax is just a very first proposal
modelResource: "entity(F3\TYPO3\Domain\Page)"

//Files/ResourceManager. Any syntax proposals so far?
//As I have no real proposal for file handling, and this is not that important right now, I'll skip this resource in my 
further proposals...
fileResource: "file(...)"


Those resources can be structured in a hierarchy:

theIntegrativeResource: "deleteMethods && modelResource"



Then we can define roles, which can also be structured in a hierarchy, this should be relatively straight forward like this:

roles:
     ADMINISTRATOR: []
     DEVELOPER: []
     CUSTOMER:
     PRIVILEGED_CUSTOMER: [CUSTOMER]


To model the effective privileges a role has on a certain resource we set up ACLs. The basic principle looks like this:

acls:
     ANONYMOUS:
     ADMINISTRATOR:
       deleteMethods: ACCESS_GRANT
       modelResource:
         -
	  ADD_GRANT
	  READ_GRANT

This seems to be quite good but we need a lot more flexibility in the policy. The following proposal extends the 
privilege assignments (ACCESS_GRANT, ADD_GRANT...):


Restrict method executions based on method parameters:

deleteMethods:  ACCESS_DENY($param.check > 10)
//execution is only allowed, if method parameter "check" is greater than 10.


Accessing the attributes of the current security context (e.g. the attributes of the logged in user):

deleteMethods:  ACCESS_DENY($context.user.isChief == TRUE)
//Access the user object in the security context and check if the isChief attribute is set to TRUE


For entity resources we must be able to access the attributes of the entity objects:

modelResource: UPDATE_GRANT(modelResource.user.department == $context.user.department)
//updating these objects is only allowed, if the the department attribute of the logged in user ($context...) is equal 
to the department attribute of such an object. That means a user can only update objects that belong to his department.


Of course you are able to combine all these constraints with logical operators like || and &&.


Another point would be to group privileges:

  privileges:
     manage: READ_GRANT, ADD_GRANT, REMOVE_GRANT

Now you can assign the manage privilege, instead of assigning every single privilege:

acls:
   ADMINISTRATOR:
     modelResource: privileges.manage(<some constraint>)



This might all be a bit confusing or complex. But it would be really interesting to hear what you think about it and 
especially how a syntax could look like to cover all these scenarios. Or do you have any scenario we cannot handle with 
this policy concept?

Nothing is final yet, so please tell me your ideas! I'm really looking forward to this.

Greets Andi