Guards can not be used with api-tools-mvc-auth

[tems99]

Hi,

I tried using this with laminas api-tools but can not get the guards working. From my understanding, the guards have a higher priority in the execution of events. Because they have higher priority, the guards are executed before authentication events in api-tools-mvc-auth. The authenticated identity could not be retrieved by the time the guards are executed.

Does anybody else have the same issues?

[visto9259]

Hi @tems99,

I am using LmcRbacMvc in a api-tools apps but only to deny access to some routes, regardless of the authentication status (and I do this because I am using packages that adds routes that I don't want the user to navigate to).

The guard listener priority of -5 while the api-tools priority for authentication is -50 if I understand it properly.

Can you explain your use case for using a guard (is it a route or controller guard?) that checks user authentication in a api-tools apps?

Are you trying to control api calls based on user roles? If so, I think using a route guard may not be the best avenue. api-tools authorization scheme can probably be augmented to use the role providers of LmcRbacMvc but I have not investigated that further.

[tems99]

I am using api-tools-oauth2. I used the ControllerPermission guards but when I step through the debugger, I noticed that the guards run before the AuthenticatedIdentity is set. I gave up on using guards and instead check permissions in controllers and services. It would have been nice to use guards since they run early and is easier to add through config.

Additional information The guards run earlier than EVENT_AUTHENTICATION_POST. Information about the event is in the link below. I have confirmed this by stepping through the debugger. https://api-tools.getlaminas.org/documentation/auth/advanced

I am trying to control api calls based on permissions rather than roles.

[visto9259]

Using the guards provided off-the-shelf by LmcRbacMVc will not help here. These guards were not meant to be used with api-tools.

However, there are a few options to explore:

• LmcRbacMvc can be extended by adding customs guards. In a custom guard you can set the EVENT_ROUTE priority such that the guard runs after the authentication process has occured. I think setting the priority to -16 would do it. Then do the necessary checks in your guard. One simple way would be to simply extend the ControllerPermissionGuard and set its priority to -16. This would provide a RBAC based on api-tools services (ie the service is authorized or not). Customs guards are documented here
• Add a listener to the EVENT_AUTHORIZATION and process the MvcAuthEvent built by api-tools-mvc-auth. It woud be more work but you would have the added benefits of asserting permissions on more granular basis, like methods (GET, POST, PUT, etc.)

This is an interesting use case for developing extensions to LmcRbacMvc to support Rbac in api-tools. I will add this to the list of possible lm-commons packages.

So if you try any of these options and you are willing to share your code, let me know so that we can generalize it into a package.

[tems99]

• LmcRbacMvc can be extended by adding customs guards. In a custom guard you can set the EVENT_ROUTE priority such that the guard runs after the authentication process has occured. I think setting the priority to -16 would do it. Then do the necessary checks in your guard. One simple way would be to simply extend the ControllerPermissionGuard and set its priority to -16. This would provide a RBAC based on api-tools services (ie the service is authorized or not). Customs guards are documented here

I completely missed creating custom guards. Will try it.

• Add a listener to the EVENT_AUTHORIZATION and process the MvcAuthEvent built by api-tools-mvc-auth. It woud be more work but you would have the added benefits of asserting permissions on more granular basis, like methods (GET, POST, PUT, etc.)

This is the better approach. I am currently using the existing Authorization functions in api-tools-mvc-auth. Combining them with permissions would certainly be better.

So if you try any of these options and you are willing to share your code, let me know so that we can generalize it into a package.

Will certainly do.

Thank you for taking the time to reply.