Assertion dependent on Authorization interface

[Wilt]

We are building a Rest API and are using an authorization module that is heavily inspired by zfc-rbac. One problem we ran into (and among the reasons why we had to make our own module) was that the assertions class (AssertionInterface) takes an AuthorizationService as an argument.

The API is able to push resource representations of newly created resources to clients/users that are online.
Like this we keep the cached model on the client up to date.

These resources we push to the client(s) render with resource privileges/permissions and these can be different for each user. To render these privileges we need to use the assertions without an AuthorizationService (since the authenticated user (the Identity in the RoleService set in the AuthorizationService ) is not who we are rendering for).

Setting a different $identity in the RoleService or setting another RoleService instance in the AuthorizationService during rendering felt very counter intuitive (and even dangerous).
I considered instantiating a new AuthorizationService for the identity/user we are rendering for and use this instance only for rendering, but it felt very uncomfortable to create an AuthorizationService merely for the purpose of rendering my resources with the correct privileges/permissions.

In the end I ended up changing my assertion model and I made an AssertionInterface that takes $identity (IdentityInterface) as a parameter instead of AuthorizationService. This allowed me to use my assertions with other then the currently authenticated Identity.

So what it comes down to is I need to get information on privileges/permissions for a certain identity without having this identity authenticated (so intuitively I would say without an AuthorizationService for this Identity in my application).
Why is the AssertionInterface actually taking an AuthorizationService as an argument instead of an Identity?

Any thoughts on this?

[danizord]

Why is the AssertionInterface actually taking an AuthorizationService as an argument instead of an Identity?

Because you may want to use AuthorizationService to check something in your assertion. We don't pass IdentityInterface as argument because you can always fetch it from AuthorizationService instance.

In next major version of ZfcRbac (v3) we will make AuthorizationService stateless, so that you can pass the identity as argument to isGranted(). And AssertionInterface#assert() signature will be likely the same of AuthorizationServiceInterface#isGranted():

// AuthorizationServiceInterface
public function isGranted(IdentityInterface $identity, $permission, $context = null);

// AssertionInterface
public function assert(IdentityInterface $identity, $permission, $context = null);

That would solve your problem. Of course it makes AuthorizationService more hard to consume because consumers will need to know the identity, but on other side the PSR-7 request attributes will make it easy to carry the identity instance between middlewares, and ZfcRbac v3 will target middleware concept.

[Wilt]

Thanks for the answer @danizord.
I think a proper AuthorizationService should not be identity aware and I think making it stateless is totally legitimate.

I do miss though a $resource in this assertion method. The result (privileges/permissions) returned by our AuthorizationService doesn't only depend on the passed Identity instance but also on the passed Resource instance. In the current solution where AuthorizationService is passed as a param we could fetch the Identity (like you suggested) with $authorizationService->getIdentity() but like that we could as well get the Resource using for example $authorizationService->getResource(). With the suggested interface:

 // AssertionInterface
 public function assert(IdentityInterface $identity, $permission, $context = null);

How would I go about that with this implementation? Or is your $context what I call $resource?

An example for a resource dependent Assertion could be: assertBlogPostIsPublic.

When will v3 be released?
Where can I find dev branch for this release so I can test whether it would indeed suffice my needs? Or is this simply the develop branch in the zfc-rbac repository?

[Wilt]

@danizord Can I find a preliminary version of v3 somewhere? Or a develop branch?

[danizord]

@Wilt

I do miss though a $resource in this assertion method. The result (privileges/permissions) returned by our AuthorizationService doesn't only depend on the passed Identity instance but also on the passed Resource instance. In the current solution where AuthorizationService is passed as a param we could fetch the Identity (like you suggested) with $authorizationService->getIdentity() but like that we could as well get the Resource using for example $authorizationService->getResource()

Actually, what you call resource is the $permission, what identifies the action that identity is trying to do.

Can I find a preliminary version of v3 somewhere? Or a develop branch?

There is the develop branch where @bakura10 did some work on 3.0. You can see some discussions and changes about 3.0 in issues and pull requests of milestone 3.0.0. Mainly #307.

Unfornunately we are not using ZfcRbac in our current project so we are not having time to work on 3.0 for now 😢, but there are a lot of apps running in production with ZfcRbac and we will certainly use it in next projects that needs role based access control, so the repo is a bit without activity but the project is not dead :)

Having said that, if you want to work on it, please feel free to open pull requests and discussions, I'm here to support you.

[Wilt]

@danizord
No, what I meant with a $resource is something else than a $permission but correct me if I am wrong.

For example a permission could be create, read, update, delete.
A resource could be for example a Post, Comment or User

Thanks for the update. We have something working right now, I can see if I will propose some more PRs in this branch in the future. It is a pity that the work on the repository came to a halt.

[danizord]

For example a permission could be create, read, update, delete. A resource could be for example a Post, Comment or User

In ZfcRbac we don't have concept of "resources" like in ACL. In this case we tend to concatenate the subject and action in permission name: post.create, post.read, post.update, post.delete...