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

Robert Lemke robert at typo3.org
Fri Jul 3 11:24:39 CEST 2009


Hi Andi,

generally I think that it is an advantage sticking to the syntax known  
from AOP pointcut expressions and named pointcuts because once a FLOW3  
developer gets the idea he can easily handle both.

> 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]

Speaking of roles: I suggest to not make them all uppercase because  
that means "constant" which is not true in this case. As far as I  
understand it, there can be any number of self defined roles, right?  
Therefore "Administrator" is just a name of a role, similar to our  
application contexts.

roles:
    Administrator: []
    Developer: []
    Customer: []
    PrivilegedCustomer: [Customer]

Sounds pretty self-explanatory.

> 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...):

In this case I think that "ACCESS_GRANT" makes sense because it gives  
a hint on a built-in privilege.

acls:
    Anonymous: []
    Administrator:
      deleteMethods: ACCESS_GRANT
      modelResource:
         -
         ADD_GRANT
         READ_GRANT

The only problem I see with the above structure is that you really  
have to know what means what (ie. below "acls" is a list of roles  
which contains a list of resources. However, it's not that difficult  
either, so we can just accept that.

The beauty is it's simplicity because it reflects what an ACL is about.

I'm not really sure about the privileges: ACCESS_GRANT etc. are all  
built-in. Is there a manageable number of privileges?

ACCESS_GRANT
ACCESS_DENY

READ_GRANT
WRITE_GRANT
ADD_GRANT
DELETE_GRANT
...

What's really the difference between them? How would they be  
implemented?
I think that for example UPDATE or ADD are very difficult to realize.

I guess we can generally break it down to

a) method access privileges and
b) property access privileges (through getters, setters etc.)

However, b) is essentially a) only for a special group of methods  
following
a certain naming convention.

What would happen here?

acls:
    Administrator:
      deleteMethods: ADD_GRANT

I could imagine that we implement the READ, WRITE, UPDATE ... cases by  
some predefined
resources:

acls:
    Administrator:
      FLOW3.actions.delete: GRANT
      FLOW3.actions.all: GRANT
      FLOW3.objects.read: GRANT
      FLOW3.objects.update: GRANT
      FLOW3.objects.create: DENY
      News.foo.bar: GRANT

(the combination doesn't makes sense, just for demo)

So the idea is that FLOW3 provides some built-in resources (all  
"deletAction" methods etc.)
and the privileges are boiled down into GRANT and DENY (maybe we need  
some BARGAIN privilege?).

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

how about that:

acls:
    Administrator:
      MyApp.generalStuff.deleteMethods: DENYIF(parameters.check > 10  
&& parameters.foo == 'bar')

> 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

acls:
    Administrator:
      MyApp.generalStuff.deleteMethods: DENYIF(context.user.isChief)

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

resources:
    TYPO3.domain.model.content.page: class(F3\TYPO3\Domain\Model 
\Content\Page)

acls:
    Editor:
      TYPO3.domain.model.content.page: GRANTIF(properties.author ==  
context.user.name)

> 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

If we have predefined resources, grouping privileges doesn't make  
sense anymore, do they? In fact the whole "privileges:" section would  
be needless.

> Now you can assign the manage privilege, instead of assigning every  
> single privilege:
>
> acls:
>   ADMINISTRATOR:
>     modelResource: privileges.manage(<some constraint>)

I don't know how to solve that with my current proposal.

So, just something to think about. My proposal surely has some blank  
spots but maybe it gives you some additional ideas.

Cheers,
robert




More information about the TYPO3-project-5_0-general mailing list